Q1. How has the proliferation of modern development practices like microservices, serverless, cloud native, infrastructure-as-code and API-first architectures impacted requirements for application security?
Modern development practices have greatly complicated application security. Most application security teams come from the network side of security. By adding these additional complex design principles, teams will struggle to address them. In today's world, developers are required to be part of the application security team, or the program will struggle.
For example, with APIs, the attack surface is increased. APIs are essential for any application being developed. They support websites, mobile applications, B2B and more. Security tools only cover certain aspects of API security, but what about the other parts that are not covered? Developers have the knowledge on how to properly threat model APIs from a security standpoint.
Concepts of cloud native, dynamic environments, and serverless are foreign to even some of today’s developer teams. The skills required to work in the cloud are highly specialized and require additional training. Correctly understanding zero trust concepts, identity management, granular security policies, compliance, and security automation is beyond your typical resource. The new world we are living in requires a village to support the application security program. Not to mention microservices.
Microservices, infrastructure as code, and the current design architecture can be amazing when properly implemented. However, the architecture and knowledge to support them from a security standpoint can be challenging to find.
What all of this means is that developers must stay current with today’s technologies and trends, and so does your application security team. Application security has moved beyond the concepts of simple scanning into the world of complex architecture.
Q2. What are some of the biggest barriers to developing effective application security programs? How are forward leaning organizations addressing these challenges?
Application security faces many barriers to success. The fundamental problem is that developers do not understand how to write secure code. Spending on scanning tools is pointless if developers don’t know how to write secure code; they'll keep adding to security tech debt with every release.
Building an effective AppSec program means training developers how to write secure code and working up from there. Security tools receive a bad wrap when it comes to working with security and developers. Security teams that do not have developers on them typically will give unfiltered security findings directly to the developers. This does nothing more than create additional backlog items to be worked without proper prioritization.
Another barrier plaguing security programs is how vulnerabilities are treated. Security findings are bugs and poor programming practices. QA should be part of the security process, but typically left out. For example, a security finding related to SQL injection is nothing more than development taking a shortcut by concatenating a string instead of properly parameterizing SQL.
When QA is part of the security process, they will know which vulnerabilities were identified, which should be addressed, and which can be ignored—similar to how they identify issues during their testing. If QA understands they had 10 critical findings, 1 addressed, and 1 created, they should fail the release. Fixing the 1 critical finding doesn't mean they can create another. Each finding addressed is 1 less vulnerability in their system.
Silos and communication issues are rampant between security and developers preventing both teams from being able to communicate back and forth effectively. Some teams will not allow developers to communicate with anyone outside of their team. Even though security should be allowed to communicate, they can’t. Siloes need to be addressed, and walls need to come down.
Q3. What key innovations or capabilities does Mend plan to highlight at Black Hat Europe 2024?
Mend.io will highlight our AI capabilities and unified platform (holistic view). Mend.io is leading the way in identifying malicious and compromised AI models. The ability to understand which AI models are integrated into your software applications is critical to understanding your threat model. Two additional vital aspects of our AI offering are both licensing and AI-BOM. Understanding what licenses your AI models are using prevents unintentional license violations and helps raise awareness of risks to the development teams. Finally, AI-BOM provides visibility into the AI components and dependencies used in your applications. This transparency will ensure that teams make informed decisions about their use of AI.
The unified platform provides a holistic view of an organization's security posture. To better prioritize security findings, knowing that a given security finding has additional exploitability will ensure that it’s better prioritized by both security and development teams. An additional benefit to the unified platform is the ability to have a comprehensive dependency inventory. This is key to addressing zero-day findings quickly and efficiently. The policy engine has seen a considerable improvement and brings a lot of new functionality to the platform. The downstream effects can be felt in the CI/CD pipeline, such as failing builds or notifications.
The unified platform has greatly improved the user experience. The goal of this improvement is to provide an enhanced user experience where both security and developers can interact with the data easily. Mend.io still focuses on keeping results where developers work most often, the SCM environment. But this improvement enables them to work easily in the unified platform as well.