blog

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

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

Explore the critical cybersecurity implications of CVE-2024-23917 and CVE-2024-27199 vulnerabilities in JetBrains software. Learn how vulnerability management and EPSS guide organizations in strengthening their cyber defences.
Francesco Cipollone
Explore the interplay between the MITRE ATT&CK framework and EPSS for effective vulnerability management. Learn how these tools help predict and prioritize cyber threats, with deep dives into the most and least exploited techniques. Stay ahead in cybersecurity with Phoenix’s advanced analysis.
Francesco Cipollone
The Cloud Security and AppSec teams at Phoenix Security are pleased to bring you another set of new Phoenix Security features and improvements for vulnerability management across application and cloud security engines. This release builds on top of previous releases with key additions and progress across multiple areas of the platform. Application Security Posture Management – Team Graph – Team Dashboard Access Update Asset and Vulnerability Management – Saved Filters – Introducing Asset Lifecycle Management – Introducing Vulnerability Lifecycle Management Integrations – Out-of-the-box Nuclei Scanning – Wiz Integration – Control Snyk ignored vulnerabilities Other Improvements – Navigate to Asset from Impact Explorer chart – Improved display of Impact and Exposure in Risk Elements
Alfonso Eusebio
Explore ASPM’s role in modern application security, offering a panoramic view that extends beyond code vulnerabilities. This guide demystifies concepts like traceability, reachability analysis, and asset lineage, pivotal for securing digital assets. Learn how ASPM empowers organizations with actionable insights for precise vulnerability management. #Cybersecurity #ASPM #ApplicationSecurity
Francesco Cipollone
Explore the transformative role of ASPM in cybersecurity. Uncover how Application Security Posture Management aligns business and security objectives for effective vulnerability management and risk reduction. Discover Phoenix Security’s innovative approach to tackling the staggering challenge of CVEs with a strategic focus on prioritization. #ASPM #Cybersecurity #VulnerabilityManagement
Francesco Cipollone

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.