Working as a security engineer I’m heavily focused on helping teams maximise the security posture of the systems they build, without introducing bottlenecks. We have access to many tools and the teams are building many products and services, it can be a challenge to find the right balance, when often one size does not fit all. Different risk appetites, different languages and platforms, different ways of working, and much more mean we need to be flexible in our approach. We want security to be accessible for everyone and that’s one of the foundations of building an exemplary security culture within a business.
When it comes to remediation of vulnerabilities there are various steps we can take to ensure we're efficiently securing our software. Each step has a time cost we need to be acutely aware of, as a result we will endeavour to automate as much as possible.
Observability
We need to understand which software is affected by the vulnerability in question. We can use a Software Bill of Materials (SBOM) or a vulnerability scanner to quickly discover the systems which need our attention.
Understanding
By understanding a vulnerability we can investigate and see which instances of the vulnerability are actually exploitable. The more sophisticated vulnerability management tools will provide additional context to help understand the risk associated with the vulnerability within our environment.
The approach
There are often multiple solutions to ensure the vulnerability is not exploitable. The most obvious is to patch by updating the dependency to a version that is no longer vulnerable, but a more cost effective mitigation might be to ensure it’s not exploitable via other mechanisms, such as network isolation. In practice these alternative approaches to patching are usually only explored in legacy software which is end-of-life with no simple migration path to a suitable alternative.
Regression testing
We want to ensure whatever approach we take there will be no negative impact by introducing the change, this means we want to ensure sufficient regression testing has taken place before deployment. With robust automated testing, in combination with instrumented observability of our systems, we can have confidence in our deployments.
Deployment
In modern systems we deploy small iterations frequently, but this is not always the case. We may need to prioritise the highest risk systems first before rolling out any fixes to production.
Each of these steps helps to prioritise security alongside feature work. With modern tooling we can automate a large portion of vulnerability remediation, but there will always be some level of manual intervention required by software engineers, as a result we want tools to be suitable and the relevant processes to align with the team's ways of working.
What do the compliance frameworks and certificates say?
They don’t care.
The nature of most compliance guides means there is unfortunately no room for context or nuance; it views a subjective field in black and white. Do you use a third-party package with a critical vulnerability? Fail. It doesn’t matter whether it’s exploitable, and it doesn’t matter if the tool the auditor is using is overzealous in its rating of the vulnerability.
Cyber Essentials Plus is a prime example where the requirement is zero critical or high vulnerabilities - the guidelines overlook cloud configuration findings, host configuration findings, data findings, secrets, network exposure, attack surface, etc.
The certificate providers are trying to treat legacy and modern software development the same, and the auditors have no idea how to keep up with the expanding platforms we now leverage. It used to be a server the company had control over, now everything is in the cloud where we leverage a shared responsibility model. Serverless architectures are better served with agentless scanners, which simply aren’t commonplace amongst auditors.
The problem
At a high level you might think so what? Vulnerabilities are getting patched. But, there is so much more to what makes a system secure, and businesses are operating with finite resources.
To acquire a certificate, which often will have a direct impact on the revenue of a business, you may have to compromise on the overall security of a system to satisfy a vulnerability requirement. Overlooking important factors which can introduce toxic combinations of security issues, such as excessive privilege and network exposure.
What’s more of a security threat to a business, a static webpage with no sensitive data that uses a vulnerable package but doesn’t even use the vulnerable part of the package code, or a poorly designed admin panel which is publicly exposed and has high privileges within the network, but it has no known vulnerabilities (yet)?
My issue with audit cadence
The frequency of audits reminds me of government budgets, where progress is only reviewed twice a year by the Office for Budget Responsibility (OBR). For such an important facet of society, and in an age of technology and data why can’t this be continuous, or at least on a more regular cadence? I feel the same way about compliance audits.
There are unknowns and plenty of smoke and mirrors prevalent in the compliance space and you only have to be compliant during the audit period to attain your certificate. I’d like to see this automated in the future, and a threshold applied to be awarded your certificate at the end of the year - I’m thinking in a similar way to how Service Level Objectives (SLOs) with error budgets work in the Site Reliability Engineering (SRE) world.
Final thoughts
Compliance frameworks should be the baseline for security posture, but often they hinder us. Unfortunately in regulated environments we have to make the decision to sacrifice the greater security posture, and sometimes the principles of our security culture, to acquire these certificates or make extra investments to maintain both.
These constraints should not deter us from pursuing the best approach to securing our products and services, but it’s an unfortunate obstacle we will have to navigate until the compliance frameworks modernise.
Certificates should be a sign of excellence, and at present they’re too easy to acquire and are not a legitimate reflection on how secure a company's software is.
