Overview #

Vulnerability management, particularly in the Application Security space, can be overwhelming. Even if you have a CICD pipeline that ensures all of the code in your version control system gets scanned, it can be very difficult, particularly for a centralized security team, to know which of those vulnerabilities are actually consequential to the business. For example, if I have a critical finding, but the code it’s found in is a Python script that my coworker Bill uses once a month to automate an inconsequential process, should that be prioritized over a high finding, in say a publicly exposed web application- maybe? The answer is, it depends on the context. Specifically, the business context. 

How does this piece of code support the business, is it part of an automation/app that enables a critical business process? Is it handling the company’s most sensitive data? Is it being deployed to isolated OT systems, or is it publicly accessible via the cloud? These are all questions that can help us to prioritize which vulnerabilities we need to fix, given their impact to the business if exploited and likelihood of being exploited. 

Now, it’s not all that uncommon for centralized security teams to lack this context around the code repositories they’ve enabled scanning on, and as a result when they identify serious vulnerabilities they have to reach out to developers and either A, the developers recognize the severity and work with you, or B they push back stating that the risk isn’t significant because the code isn’t supporting anything important, isn’t easily exploitable, etc. To be clear, in scenario B, it’s good that the developers push back, but these manual conversations are slow, painful and extremely inefficient. 

Case Study: #

Background #

There was a company, who shall remain nameless, that I had the pleasure of interacting with, that had a large number of developers. The company itself was fairly unusual in that the developers did not report up to one division/business unit/leader. They were dispersed throughout the organization. The code they were working on was also highly diverse. Some folks were writing firmware for medical devices, others were building publicly facing APIs, others still were deploying machine learning services. 

They didn’t have a centralized compute platform that developers could hand their applications off to for hosting (https://tag-app-delivery.cncf.io/whitepapers/platforms/), so the developers were also often in charge of maintaining infrastructure as well. Finally, with well over 16,000 repositories, you could imagine the number of vulnerabilities festering in their code bases. Documentation or Infrastructure as Code was also hit or miss. So what did they do? 

Their solution: start simple:  #

The team made a requirement for what I call business context as code. If someone has already coined this idea, please let me know and I’ll give them credit. Otherwise, DIBS! In their implementation, the business context as code was a simple YAML file structure like so:

business_criticality: critical # Options: critical, high, medium, low
deployment_context: public_customer_facing # Options: public_customer_facing, internal, airgapped
uptime_reqs: 24_7 # Options: 24_7, business_hours, monthly, on_demand
last_reviewed: ”2025-06-26”

They ensured this was present using GitLab Pipeline Execution Policies which would inject a check into all CICD templates to ensure the project contained a file called business_context.yml, and if it didn’t find it or saw that it hadn’t been reviewed in a year it warned you that this needed to be created/updated with steps on how to do so. For cases where the code wasn’t updated frequently there was a PEP that ensured all repos got checked once a week, and the repo owner would get a warning if it wasn’t present or up to date. 

To make the lives of developers easier, they also built a nice front end (form) so developers have a place that explained what each of the terms meant, how to determine them for your repo as well as a section that captures their answers and sends them to a gitlab pipeline that would create a correctly formatted yaml on behalf of the dev and stick it into the repo they specified. 

This idea works because, like architecture as code or infrastructure as code, it slots into the software development process more easily, and feels more familiar to developers. 

How does business context as code help with vulnerabilities? #

Well, with something as simple as a yaml file documenting this information, you can build a vulnerability scoring framework to rank which repos and corresponding vulnerabilities need to be prioritized. It can be as simple as a scorecard system, where for each category your choice corresponds to a score. If you sum all the scores across categories you get a final “risk score” and depending on what range your “risk score” falls into you can specify remediation timelines. This can look like the following:

So each selection corresponds to a number, and you can have a remediation recommendation framework based on the total sum of numbers selected:

Once you’ve identified which repositories are high risk, you can possibly label them with compliance frameworks (at least for GitLab) to raise the floor for security in those repositories. If you use something like DefectDojo for this type of vulnerability management, you can also specify SLAs or reclassify the vulnerabilities. Again, this isn’t meant to be sophisticated, but something to get you started. There’s a lot you can build on top of this. 

Added benefits of business context as code #

With this you can now start to build an inventory of repos based on impact, which will help security teams decide who they need to focus on partnering with. Additionally, as AI becomes ever present, this is the sort of context agents are going to need to be useful in security. Daniel Miessler has spoken about this a ton. Here’s a great post of his on what he call Unified Company Context. This a slightly different idea, but it might help to build up that catalog of context for a business. 

Lastly, getting this information can help you justify additional investment in your application security capability/program. Once you aggregate the information, you’ll have quantifiable metrics to show leadership for your appsec risks, and if you can tie those risks to business impact from a financial perspective you’ll have a much stronger argument. 

For example, you’ll be able to tell a story like the following: We have 5 code repos that support processes that generate $XXXXX’s of dollars for the company. They are currently under high risk for compromise as they have Y critical (easily exploitable vulnerabilities) while being publicly accessible, meaning any attacker in the world can potentially exploit them. We need to take steps Z, A, B to mitigate this, and here’s the cost of mitigation. This translation of cyber findings to business risk is key for getting executive/business buy in.