Summary
If you’re thinking about application security training for developers, it’s crucial to think about setting common KPIs for development and security teams, so that everyone is working towards the same goals. This article explains why a shared culture around security is so important, and names the metrics to focus on for best practice DevSecOps management.
Setting Key Performance Indicators (KPIs) is one of the most common ways for organizations to measure the success of their teams. In this article, we will talk about why it’s important for security and development teams to set and measure a shared set of KPIs as part of a security-first culture across the business, as well as how to encourage developers to see their shared responsibility through new eyes.
Why Does Application Security Training for Developers Matter?
There was a time when it simply wasn’t the remit of developers to care about security. They focused on building software applications, and let security teams take over to handle internal and external threats. That time has long gone, and today the idea of DevSecOps management means that development, security, and operations teams have a shared responsibility to secure applications across the software development lifecycle (SDLC). By integrating security into the SDLC, applications can be more inherently secure, and vulnerabilities can be found a lot earlier, reducing rework and costly fixes later in the process, and making it easier to recover from any problems as they occur.
While developers are not usually security experts, with the right culture you can make sure that every person in the business cares about security, and has the tools to take autonomy over security as it relates to their role. For example, software developers will be able to scan code directly from the Integrated Development Environment (IDE) to check for vulnerabilities, and all developers will take part in secure code training to learn secure coding best practices. When it comes to application security and getting developers on board, the better the tools and processes are for developer experience, the less likely it is that developers will feel friction and push back against the expectation that security is now part and parcel of their role.
Creating Alignment between Security and Development Teams
To create a security-first culture, security and development teams need to have their eyes on the same prize, and this starts right at the top of the organization. KPIs are a way to measure success, and so comparing the KPIs of each team will uncover whether objectives are aligned. Having shared KPIs ensures that priorities are shared between teams. Without shared KPIs, development teams and security teams may be focused on misaligned goals.
As part of Gartner’s 2023 Security in Software Engineering survey, it was found that development teams were far more likely to focus on metrics such as speed of delivery, frequency of release, and team productivity when considering KPIs — while security teams had their priorities set around vulnerabilities identified and remediated, as well as mean time to detect vulnerabilities. While this isn’t surprising, it paints a picture of teams that are working in silos, and not considering the wider organization’s needs. For DevSecOps to work, security teams need to recognize that development teams have tight deadlines to manage, and development teams need to start thinking about risk reduction in the way that they work. Luckily, the right tools and processes will allow for both objectives to be met.
Which Security Metrics Should Development Teams Feel Accountable Over?
Gartner research also discusses which specific KPIs are the most common for security teams to hold software engineering teams accountable for. These are a strong baseline for discussing shared responsibility in any DevSecOps environment. They include:
- Time to incident resolution: This could be measured in minutes, hours or even days, and allows you to understand how quickly security incidents are being closed. This KPI can help to start a conversation around additional tools, training, or processes that could help developers to fix issues with autonomy, speeding up the Mean-Time-to-Resolve (MTTR).
- Mean time to resolve critical vulnerabilities: In many organizations there may be many vulnerabilities, but that doesn’t mean that they are all critical ones. This can cause problems such as alert fatigue, where teams ignore notifications, or find it hard to prioritize effectively. If, like most companies, you have too many vulnerabilities to solve in full, you can focus on MTTR for the most critical, if you have the visibility to do so. For this KPI, you need a way to analyze and prioritize vulnerabilities by their level of exploitability or risk.
- Number of vulnerabilities identified: Not all vulnerabilities become a security incident, and with the right tools in place — you will be able to tune out the noise, including false positives, low, medium and information severity vulnerabilities, and focus in on critical vulnerabilities that are most in need of fixing. Tracking critical vulnerabilities gives you a more accurate picture overall, and reduces issues such as alert fatigue.
-
- Number of vulnerabilities remediated: It’s interesting to see that 50% of security teams hold developers accountable for identifying vulnerabilities and 64% of security teams hold them accountable for remediation. In reality, a holistic application security platform should empower developers to both identify and fix vulnerabilities as often as possible, as this will lead to better coding practices and a security-first culture across the SDLC so that fewer vulnerabilities get coded in the first place.
- Number of security incidents: This metric helps an organization to understand both their workload and risk levels, recognizing whether additional staff are necessary to handle the load, and also whether the number of incidents is going up or down. Alongside what kind of incidents these are, it could also uncover new attack vectors or insecure working practices that need to be addressed.
- Number of policy violations: Development and security teams should be working together to build policies that support both agility and risk reduction — so that these policies work in a fast-paced yet secure DevSecOps environment. When these are agreed upon, policy violation metrics can be used to make sure that they are being kept to across the org, and that compliance regulations and internal governance are front and center.
- Mean time to detect vulnerabilities: When security and development teams are aligned and have the right toolset, detecting vulnerabilities can become part of a streamlined shared culture of responsibility. Security teams are able to focus on fire-fighting unexpected threats, while development teams can detect and remediate vulnerabilities throughout the SDLC in real time where they work. Tracking MTTD and watching it get lower means celebrating the success of this partnership.
How Checkmarx Enables Secure Coding Best Practices through DevSecOps Management
In order to make developers take accountability over these KPIs, they need to be able to move those needles themselves, with autonomy. That means making sure that development leaders have a seat at the table when security priorities and policies are written, providing the right education and training to development teams, and critically — adopting the tools and platforms that support a security-first culture and promote developer experience.
At Checkmarx, we are focused on integrating and automating security as part of the development process, and helping enterprises to streamline their DevSecOps management. We know that developers can often feel like security is slowing them down, and our holistic application security platform provides all the tools enterprises need to integrate security without it becoming a hurdle to innovation and speed.
Checkmarx One fosters collaboration to build trust between developers and security teams, with automatic scans integrated across every stage of the SDLC, including SAST, DAST, SCA, IaC security, and more. Your developers can take control over securing the whole application lifecycle from the first line of code to deployment and runtime in the cloud, and all from within the developer tools they work with every day. In this way, security teams can bring security to the developers — rather than give them additional work or the friction of moving between tools. With shared KPIs, developers can see their actions having a measurable impact on organizational goals — increasing both morale, and the readiness to be active in risk reduction.
Looking to empower your development teams and make security part of their everyday working practices? Schedule a demo of Checkmarx One.