Vulnerability, Infrastructure and Application Security SLA, SLO, OKr – Do they matter??

SLA

This blog is part of a series of articles out of the whitepaper Download Whitepaper – Data-Driven Vuln Management – Are SLA dead

Vulnerability and their resolution for application security, devsecops, there have been a lot of changes in recent times. 

How do you measure and facilitate the best way resolution of vulnerabilities without crashing the spirit and soul of the development team with the dreaded sentence, fix vulnerabilities in X number of days? 

Let’s start by clarifying that development teams have the will and spirit to write perfect code and solve vulnerabilities. Businesses need to ship features fast to increase revenue, augment the sales surface, winning more clients. 

Those two elements have always been conflicting, and the security requirements (often not at the start of the project) is lacking in the objective of application owners or business. 

From this challenge, developers often lack the time and objectives to resolve vulnerabilities and bug fixes sprint by sprint. 

So how can this be fixed? In several days, security mandates to fix problems (vulnerabilities, bug fixes, misconfiguration, libraries). The resolution times, often called SLA, are usually not agreed upon in collaboration with CTO and the development team. 

This mandate often causes friction and frustration among everyone. 

I have been having conversations with different professionals and experts in the field and had more or less argumentative discussions around SLA, SLO and OKr in Vulnerability management, Application and cloud security.

This article will cover the complexity of the landscape and the significant difference between various “updating” strategies and elements to consider when setting SLA, SLO or grouping them.

We will explore how those metrics with a feedback loop between security and development teams can facilitate a conversation and turn the tide in a usually frustrating exchange. 

Definitions

Let’s start with definitions of SLA, SLO and what they are:      

  • A service-level agreement is a commitment between a service provider and a client. Particular aspects of the service – In our specific case, SLA stands for the number of days a particular vulnerability must be fixed.
  • A service-level objective is a critical element of a service-level agreement between a service provider and a customer – Similar to SLA but is not an agreement but rather an objective. 
  • SLI – I will skip it for now
  • OKr  – Objectives to achieve (specifically in the DevOps team (something like the number of vulnerabilities per spring
SLISLOSLA
DefinitionA quantifiable measure of reliabilityA target reliability level objectiveA legal contract or agreement that, if breached, will have penalties
ExampleThe number of vulnerabilities should be < 10 for every releaseCritical Vulnerabilities will be resolved in 28 days 95% of the timePublic available products will have 0 critical vulnerability upon release critical vulnerability disclosed will be solved in 10 days 
Who Sets itSecurity teams in collaboration with Product OwnersProduct owner in partnership with security teamsBusiness Development, Legal team, IT and Devsecops 
Vulnerability and SLA/SLO/SLI Descriptions

Vulnerability Landscape

The vulnerability landscape in modern organisations is complex; we can categorise the vulnerability types or misconfiguration in several categories. Vulnerabilities in the various categories have quite different behaviour and require different levels of attention.

We can categorise assets in the following categories:

  • Application security – Vulnerabilities that concern codes, libraries or similar 
  • Infrastructure Cloud security-related – vulnerabilities that concern images or similar infrastructure systems running in the cloud
  • Cloud security – misconfiguration of cloud systems (Key manager, S3) 
  • Network security / Cloud security – vulnerability affecting network equipment like WAF, Firewall, routers
  • Infrastructure security – Categorized as everything that supports an application to run that is traditionally Server, Endpoints, and similar systems
  • Containers vulnerabilities (somewhere in between application container/cloud security with running containers, image stores and the system that composes containers

The approach to measure the security posture and the security health of different elements that compose our approach is quite comprehensive, the picture below gives a good idea.

The resolution time, hence SLAs, is fairly different between assets in the various categories.

Following is an example of the tooling that traditionally detects vulnerabilities in various containers illustrated above.

Vulnerability Landscape

Fixing landscape  

Applying patches and mandating SLA seems straightforward, but in reality, many factors influencing, fixing and resolving vulnerabilities can be a bit of a learning curve/journey. 

The reason for such a complex landscape is because the factors that influence fixing systems and resolving vulnerabilities are many:

  • System Complexity
  • Different Layer of patches 
  • Testing is required and several teams/clients involved in testing 
  • Number of groups involved in the fix
  • Exposure to clients and criticality of systems (Downtimes allowed)
  • Maintenance windows

Moreover, fixing vulnerabilities in the various system should not be delegated to just one team but rather have an objective and measurable target to discuss in the context of risk. 

Some of those elements can be automated, but mostly not; every system has different contracts and requirements. Nonetheless, those can be fed as business requirements for SLA and determine the bucket or Categories of the system for SLA/SLO/OKr.

Usually, systems are categorised into

  • Critical system – uptime is vital, and windows for updating are tight
  • Medium criticality – uptime is essential, but windows for an update are more relaxed
  • Low criticality – downtime and update windows are very flexible.

Following several different elements to consider for patching and adjusting the time for SLA, SLO, and writing OKr. 

The following is to be taken as a guideline, not as an exhaustive list of topics.

Patching / Infrastructure 

  • SIMPLE – Patch (easy) upgrade with simple testing, maintained by only one team
  • SIMPLE/MEDIUM – Patching a system with some testing requirements maintained by one or two teams
  • COMPLEX – Complex system with multiple dependencies and configurations 
  • VERY COMPLEX – Complex system with various applications and multiple teams maintaining different parts and vast client surface 

Cloud

  • SIMPLE – updating a system rule in a register, settings in a cloud element (e.g. S3)
  • SIMPLE/MEDIUM – Changing the role, IAM rule, Permission rule
  • COMPLEX to VERY COMPLEX – Restructuring the architecture of a service, introducing controls, changing access methodologies, changing settings that involve user interaction

Containers

  • SIMPLE – library or dependency without significant impact
  • MEDIUM – changing a critical library or os that potentially breaks dependencies
  • COMPLEX – updating container image with multiple dependencies and different running containers utilising the image
  • VERY COMPLEX – updating a container’s image that is used widely across the organisation e.g. Linux, with the deprecation of a function utilized by one or multiple systems

Updating Libraries 

  • SIMPLE – updating a library without critical dependencies 
  • MEDIUM – changing a critical library that potentially breaks dependencies on one application
  • COMPLEX – Changing a library from minor to major version, with deprecated libraries that require swap of those functions in multiple parts of code
  • VERY COMPLEX – similar to complex, but when the number of teams is multiple and distributed 

Update Code/ Bug Fixing

  • SIMPLE – changing a simple variable, function with a minor regression testing
  • MEDIUM – changing a function or a section of code with medium impact in the individual file or limited number
  • COMPLEX- updating a major section of the code, changing inputs from one or multiple user perspectives that requires extensive testing

Conclusion

Vulnerabilities are a complex matter and there is no one single answer that fits all.

Vulnerability resolutions and considerations around the vulnerabilities complexity of teams needs to be a collaborative process between the security team and the product/development team

Vulnerability prioritization and contextualization become key to free up the security team from deciding what to fix and what not to fix. Security teams can then turn into a more consultative and collaborative approach with the development team helping them succeed in deciding how to fix specific problems vs what to fix or not

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

The journey of securing an organization’s application landscape varies dramatically, depending on where a company stands in its maturity. Early-stage startups with small security teams face challenges not only with vulnerabilities but also with scaling their security processes in line with their growth. On the flip side, established enterprises struggle with managing complex environments, prioritizing remediation, and dealing with vast amounts of vulnerabilities while staying ahead of sophisticated threats. For startups, the focus is clear—establish visibility and ensure core security practices are in place. Application Security Posture Management (ASPM) tools provide a straightforward, automated approach to detecting vulnerabilities and enforcing policies. These solutions help reduce risk quickly without overburdening small security teams. Mature organizations, on the other hand, are tackling a different set of problems. With the sheer number of vulnerabilities and an increasingly complicated threat landscape, enterprises need to fine-tune their approach. The goal shifts toward intelligent remediation, leveraging real-time threat intelligence and advanced risk prioritization. ASPM tools at this stage do more than just detect vulnerabilities—they provide context, enable proactive decision-making, and streamline the entire remediation process. The emergence of AI-assisted code generation has further complicated security in both environments. These tools, while speeding up development, are often responsible for introducing new vulnerabilities into applications at a faster pace than traditional methods. The challenge is clear: AI-generated code can hide flaws that are difficult to catch in the rush of innovation. Both startups and enterprises need to adjust their security posture to account for these new risks. ASPM platforms, like Phoenix Security, provide automated scanning of code before it hits production, ensuring that flaws don’t make it past the first line of defense. Meanwhile, organizations are also grappling with the backlog crisis in the National Vulnerability Database (NVD). A staggering number of CVEs remain unprocessed, leaving many businesses with limited data on which to base their patching decisions. While these delays leave companies vulnerable, Phoenix Security steps in by cross-referencing CVE data with known exploits and live threat intelligence, helping organizations stay ahead despite the lag in official vulnerability reporting. Whether just starting their security program or managing a complex infrastructure, organizations need a toolset that adapts with them. Phoenix Security enables businesses of any size to prioritize vulnerabilities based on actual risk, not just theoretical impact, helping security teams navigate the evolving threat landscape with speed and accuracy.
Francesco Cipollone
The cybersecurity world is reeling as MITRE’s funding for the CVE and NVD systems expires, disrupting the backbone of global vulnerability management. As traditional sources like the National Vulnerability Database collapse under funding cuts and submission backlogs, security teams face delays, incomplete data, and loss of automation in remediation pipelines. This isn’t just a data problem—it’s a structural crisis for application security and vulnerability correlation. In this landscape of uncertainty, Phoenix Security’s ASPM platform steps up with a code-to-cloud correlation engine that doesn’t depend on outdated data workflows. By connecting code-level insights (including tools like Semgrep) to runtime and cloud environments, Phoenix enables faster, context-aware vulnerability remediation—even as NVD and CVE pipelines deteriorate. This article dives into the implications of the CVE shutdown and how Phoenix Security is helping security and development teams transition to a resilient, correlation-first approach to cybersecurity.
Francesco Cipollone
Learn how to predict ransomware risks and vulnerability exploitation using a threat-centric approach. Explore data-driven insights, verified exploit trends, and methods for assessing the likelihood of attacks with key references to CISA KEV, EPSS, and Phoenix Security’s 4D Risk Formula.
Francesco Cipollone
Remote Code Execution flaws continue to undermine Kubernetes ingress integrity. IngressNightmare (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974) showcases severe threat vectors in NGINX-based proxies, leading to cluster-wide exposure. ASPM, robust remediation tactics, and strong application security solutions—like Phoenix Security—mitigate these vulnerabilities before ransomware groups exploit them.
Francesco Cipollone
Remote Code Execution flaws continue to undermine Kubernetes ingress integrity. IngressNightmare (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974) showcases severe threat vectors in NGINX-based proxies, leading to cluster-wide exposure. ASPM, robust remediation tactics, and strong application security solutions—like Phoenix Security—mitigate these vulnerabilities before ransomware groups exploit them.
Francesco Cipollone
The recent Google acquisition of Wiz for $32 billion has sent shockwaves through the cybersecurity industry, particularly in the realm of Application Security Posture Management (ASPM). This monumental deal highlights the critical importance of cloud security and the growing demand for robust ASPM solutions. While the acquisition promises potential benefits for Google Cloud users, it also raises concerns about vendor lock-in and the future of cloud-agnostic security. Explore the implications of this acquisition and discover how neutral ASPM solutions like Phoenix Security can bridge the gap in multi-cloud environments, ensuring continuous, collaborative, and comprehensive security from code to cloud.” – Find Assets/Vulns by Scanner – Detailed findings Location information Risk-based Posture Management – Risk and Risk Magnitude for Assets – Filter assets and vulnerabilities by source scanner Integrations – BurpSuite XML Import – Assessment Import API Other Improvements – Improved multi-selection in filters – New CVSS Score column in Vulnerabilities
Alfonso Eusebio
x  Powerful Protection for WordPress, from Shield Security
This Site Is Protected By
ShieldPRO