blog

Using SLAs for Better Vulnerability Management & Remediation: Improving Developer’s Workflow

AppSec Phoenix SLA Targets
AppSec Phoenix SLA Targets
AppSec Phoenix SLA Targets

SLAs (Service Level Agreements) are pretty common among vendors and companies in the IT industries. This agreement defines all the expectations of a company from their service provider or vendor based on various metrics to measure the estimated performance.

The SLAs are also used by various departments within a company to smoothly run all operations based on certain expectations. The same goes for the Cybersecurity industry where companies sign SLAs to fix certain vulnerabilities in a 30, 60 or 90 days period.

This time period is pretty vague and arbitrary, therefore security experts rarely meet the expectations because of various reasons. Let’s dive deep and see how important is SLA for resolving vulnerabilities to help other counterparts such as developers work better.

Importance of SLAs in Vulnerability Management

Service-level agreements are adopted by many companies who deal with vendors in their industry. In the cybersecurity sphere, SLAs are also utilized by company executives to fix certain vulnerabilities in a fixed number of days or months. Many executives expect unachievable results in their SLAs, especially when it comes to fixing vulnerabilities.

For Example, many companies aim for fixing vulnerabilities with CVSS Score of 7 or above in a 30 days time frame. The security teams ask IT experts or other counterparts to fix vulnerabilities with a 7+ CVSS score in less than 30 days. These vulnerabilities are often counted as half of all other CVSS scores. It is extremely hard for security experts to achieve this goal within given time period.

Therefore, companies need to measure the extent of work before they impose an SLA to any counterparts within or outside their organization. They should use a data-driven approach to fix certain vulnerabilities first or extend the timeframe in the agreement.

Issues during SLAs Construction

Wrong vulnerability management is the root of unachievable SLA. The executives often set wrong expectations from their developers because they did not smartly manage all their vulnerabilities. The issue might arise from the wrong prioritization of vulnerabilities.

Above all, executives are also pressured to fix certain vulnerabilities before hackers find and use exploits. Hence, they often rush into fixing all major issues at once by setting wrong expectations based on faulty matrices. 

Why get SLA?

SLAs give a clear direction to the counterparts who are working to resolve an issue or solve a specific problem. According to industry research and Appsec Phoenix data, it normally takes between 180-290 days to remediate all vulnerabilities on a corporate network. 

Companies aim for high-risk vulnerabilities first, and it certainly shortens your time to fix the flaws. An SLA is effective to set the time interval for fixing vulnerabilities, but executives should use a data-driven approach to decide all factors of the agreement including service, time intervals, obligations and penalties.

It allows clarifying expectations and sets established standards for developers and other counterparts who are working to fix or patch certain high-risk vulnerabilities. A data-drive SLA is always an effective way to make developers focus better on their work rather than in internal debates.

Evidence-Based SLAs

All service-level agreements should be backed by some kind of evidence that could potentially ease the developers. This evidence is often data-driven. A normal organization only has the capacity to fix 1 out of 10 vulnerabilities. Organizations often debate over which vulnerabilities should be fixed under the SLA and these internal debates divert the attention of developers.

Today’s risk management platforms have real-time insight into mean time to remediation (MTTR) and mean time to exploit (MTTE), allowing them to provide SLA assurance recommendations that directly tie to an organization’s risk appetite. The lower an organization’s risk tolerance, the faster it will have to remediate.

Using Risk-Based SLAs

Risk-based SLAs might be the effective option for executives who are willing to support their dev teams. Companies need to assess their risk category before they determine any components of their agreement. These Risk-Based Factors are categorized as:

  • Low Risk — A company having capabilities to remediate vulnerabilities extremely fast.
  • Medium Risk — A company that wants to remediate on a faster pace than their previous performance.
  • High-Risk — A company with the lowest risk tolerance, that wants to remediate vulnerabilities as quickly as possible before a hacker finds and exploits those flaws.

The Risk-Based SLAs allow organizations to assess their risk tolerance levels. It also helps analyze two other major factors, such as the prioritization of assets upon which SLA is being set. These variables are combined to determine the timeframe recommendation for the SLA based on their risk. If executives also rely on these factors for their SLAs then it can really help developers to fix issues while meeting all the expectations.

AppSec Phoenix’s Risk Solution – Risk Indication for SLAs

AppSec Phoenix offers real-time risk-based indicators to help executives make informed decisions and develop better SLAs to support developers who act to fix those vulnerabilities. 

According to Bakermckenzie survey, the greatest third-party risks companies face in their supply chains are the insolvency of key suppliers partners and data/cybersecurity. 

We have got you covered from all third-party supply chain risks by providing detailed insights under our single pane of glass to give you an overall review of threats. Also, we provide a single aggregation point across multiple platforms to easily identify and remediate vulnerabilities. 

Bottom Line

Executives can use risk indicators to construct better SLAs for developers who work to resolve certain vulnerabilities in expected timeframes. Also, evidence-based SLAs are necessary to manage vulnerabilities effectively. Otherwise, attackers may find and exploit potential threats due to bad vulnerability management and unachievable expectations from developers. 

The Appsec Phoenix Way

With Appsec phoenix you can set your policy based targets and see where the organization is in comparison to internal and external industry targets. Check where your organization is and how to improve application security with the most advanced frictionless platform, get an appsec phoenix demo today and try it yourself

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.