Scorecards are a Cortex feature that allow you to understand how well your services are doing on the metrics you care about. Scorecards are customizable to your needs, however several are common to most organizations. In our previous post, we shared the top three scorecards that we recommend to Cortex customers.

Security maturity is one of the first scorecards we recommend organizations create. In this article, we’ll do a deeper dive on what security maturity looks like, why you should be tracking it, and how engineering leaders and security teams can partner in Cortex to meet standards across the organization.

What is software security maturity?

Software security maturity aims to answer the question, “How much can I reasonably do to reduce the risk of security incidents related to my software?” To answer this question we need to look at the likelihood of an incident occurring, and how prepared your team is for when an incident does occur. Services built with mature security practices are less likely to face security incidents, and are well-prepared for any that do occur.

Reducing the risk of a security incident happening is priority number one when it comes to security. There are a few key metrics that can help you to understand how likely an incident is to occur for your team:

• Known vulnerabilities: Security researchers often find vulnerabilities in commonly used libraries. When they do, these vulnerabilities are published under programs such as the CVE program. If your dependencies have known vulnerabilities in them, then this might leave you open to attack.

• Testing practices: Teams that thoroughly test their code are less likely to introduce vulnerabilities than teams that don’t. Aiming for high code coverage in your tests can be helpful, as can techniques like fuzzing.

• Bugs and issues: The number of bugs a service has can give you an idea of how vulnerable it might be. It’s important to treat this as a metric, and not a target. Aiming for a low number of bugs on your services could incentivize not reporting bugs in the first place.

• Dependency age: The longer a dependency has been released, the longer attackers have had to find vulnerabilities in it. It’s important to keep your dependencies up to date to reduce the risk of them introducing vulnerabilities to your services.

It’s impossible to prevent all security incidents. Being prepared for a potential incident and reducing time to respond helps to minimize the potential impact on your organization. Below are some metrics that can help measure how prepared your team is for a security incident:

• Documented owners: When a security incident occurs, getting the right people in the room quickly can greatly speed up mitigation. Often, the right people are the ones with knowledge of the affected services, and so documenting the owners for your services is critical.

• On-call rotation defined: On-call engineers are the first responders of the software world. When an issue is detected, there needs to be a clearly defined line of escalation that is well-communicated.

• Mean Time To Resolve (MTTR): MTTR measures how long it takes for issues reported during on-call rotations to be resolved. These issues aren’t necessarily security-related, but tracking how long your team takes to respond to issues in general is a great proxy for how prepared you are for a potential security incident.  Related: see how a customer used Cortex to slash their MTTR.

You can create rules from these metrics based on your organization’s goals. Below are some examples.

Example scorecard

Cortex customers can create customizable tiers of quality in their Scorecards to help benchmark status and drive progress. At Cortex, we use bronze, silver, and gold, but these can be any levels that make sense in your organization.  In this example, a service with gold security maturity has not only met the baseline requirements for security readiness, including having a connection to Snyk and Sonarqube, but has also achieved the highest standard for vulnerability remediation, with minimal open issues.  Dividing scorecards into levels gives teams more achievable goals to hit on the path to security maturity. It also encourages gamification, where teams can compete to improve their scores.  Nothing wrong with a little competition among teams if it helps out your security profile!  It also lets you quickly understand the status of your organization’s services, “50% of services achieve gold security maturity” is both easy to understand and a useful piece of information.

But where is the data comprising each rule coming from? The circular logos next to each rule in the scorecard above represent the integrations that provide data for the rule. Cortex comes pre-loaded with 40+ integrations for the tools that you already use to manage your services, including:

• Azure DevOps

• Checkmarx

• Coralogix

• DataDog

• FireHydrant

• GitHub

• GitLab

• Mend

• PagerDuty

• Snyk

• Sonarqube

• Veracode

Cortex in Action — Quick ID of vulnerable packages

Security incidents can have serious consequences for your business, including loss of revenue and customer trust. It’s critical, therefore, to minimize the risk of incidents happening and to have the ability to react quickly when they do.

In 2021, Log4j, a common open-source library was discovered to have a serious vulnerability. This vulnerability let attackers execute their own code on machines that used the library, which could allow them to steal sensitive data such as passwords or payment information. Patching this vulnerability quickly was paramount. Researchers estimated that hackers attempted to exploit this vulnerability on around 50% of corporate networks globally within days of details being published.
If your organization had Cortex when the Log4j vulnerability was realized, you'd only need to use our CQL function to search for services with the outdated package, or create a Scorecard with the following rule:

package_version("log4j") > semver("2.17.0")

You would then have been able to quickly identify impacted services, trace dependencies,  and track over time how quickly your team was able to respond. Of course, it doesn’t take a heavily publicized zero-day vulnerability for your organization to be attacked. DDoS attacks have been around for decades, and can cause you to lose revenue proportional to the time it takes to address the attack.

If you’d like to chat with us about how to up-level your software security and production readiness, request a custom demo with our team.