When every team rates security bugs differently, a cross-tenant data leak can sit in a backlog labelled "medium" while a cosmetic header finding blocks a release. A bug bar is a written, product-specific definition of security severity classes, each tied to a release rule and a fix deadline, so that the same bug gets the same rating and the same urgency whoever triages it. This guide explains how published bug bars work, using the Microsoft SDL bug bar and Chromium's severity guidelines as reference points, how they relate to CVSS, how to write your own bar with fix deadlines and release gates, and how to measure whether it is followed. It is written for engineering managers, application security teams and product security incident response teams.
Key takeaways
- A bug bar defines severity by impact in your product, such as code execution, elevation of privilege or data disclosure across a boundary, not by a generic score.
- Boundaries come first. Microsoft only services a vulnerability that violates a security boundary or feature and meets the severity bar; your bar should list your product's boundaries explicitly.
- Each class needs a release rule and a deadline. Chromium, for example, aims to ship fixes for critical issues to all users in under 30 days and for high severity issues in under 60 days, and treats exploitation in the wild as top priority with a 7-day objective.
- CVSS is an input, not the bar. FIRST's CVSS v4.0 specification asks consumers to enrich base scores with threat and environmental metrics; product context still decides the class.
- Measure adherence, not just volume. Track time to fix against the bar's deadlines, ratings changed on appeal, and exceptions by age.
What a bug bar is and why development teams need one
The term comes from Microsoft's Security Development Lifecycle. The Microsoft Security Response Center publishes the "Microsoft Vulnerability Severity Classification for Windows", also called the SDL Bug Bar, which it uses to triage reported bugs and set their severity. A bug bar does three jobs: it gives triagers a shared vocabulary, it decides what blocks a release, and it sets how quickly each class must be fixed after release. Without one, severity becomes a negotiation between the reporter, the developer and the product owner.
A bug bar is narrower than a vulnerability management policy. Vulnerability management covers scanning, patching and exceptions across an estate, while a bug bar covers the security defects in code your teams own. The two meet at remediation deadlines and exceptions; see the Remediation SLAs and Vulnerability Exceptions Guide.
Step one: define your security boundaries
Microsoft's Windows security servicing criteria decide whether a reported issue is serviced by asking two questions: does the vulnerability violate the goal or intent of a security boundary or a security feature, and does its severity meet the bar for servicing? Microsoft services only when both answers are yes, and by default considers other issues for the next version or release. Its listed boundaries include the network, kernel, process, AppContainer sandbox, user, session, web browser, virtual machine, Virtual Secure Mode and Virtualization-Based Security boundaries.
Product teams should write the same list for their own systems. Typical boundaries for a SaaS or web product:
| Boundary | Crossing it means | Example defect |
|---|---|---|
| Unauthenticated to authenticated | Acting without valid credentials | Authentication bypass, password reset takeover |
| Tenant to tenant | Reading or changing another customer's data | Missing tenant check in an API (IDOR across tenants) |
| User to user within a tenant | Acting as or reading another user | Session fixation, object-level authorisation flaw |
| Role to role | Gaining privileges not granted | Function-level authorisation flaw, mass assignment of a role field |
| Application to host or cloud control plane | Running code on servers or reaching cloud credentials | Deserialisation RCE, SSRF to an instance metadata service |
| Customer integration to platform | An API key or OAuth client exceeding its scopes | Token accepted for the wrong audience; scope not enforced |
Anything that does not cross a boundary is a defect, a hardening opportunity or "by design", and the bar should say how those are tracked so reporters get a consistent answer.
Step two: define severity classes
How the Microsoft SDL bug bar is built
The MSRC classification uses four ratings, Critical, Important, Moderate and Low, across impact categories including elevation of privilege, remote code execution, information disclosure (targeted and untargeted), denial of service, spoofing, tampering, security feature bypass and security assurances. It keeps separate bars for servers and clients and adjusts for the scenario:
- Server examples: execution of arbitrary code, arbitrary writing to the file system and SQL injection that allows code execution by a remote anonymous user are Critical; persistent denial of service against a high-value asset by an authenticated user is Important.
- Client examples: network worms and unavoidable common browsing scenarios where the client is compromised without warnings are Critical; remote code execution that needs extensive user action is Important; a local low-privilege user elevating to another user, administrator or local system is Important.
- User interaction: extensive user interaction can reduce severity in some circumstances, but ordinary actions such as clicking a link are not extensive, and elevation of privilege is never reduced below Important for this reason.
- Chaining: where a lower-class issue can be combined with by-design behaviour to reach a higher class, it is rated at the higher class.
- Default versus specific scenarios: many entries distinguish a common or default configuration from a specific one, which changes the rating.
How Chromium's severity guidelines are built
Chromium publishes four severity levels, S0 to S3, defined by what an attacker gains in the browser's own model. Critical (S0) issues let an attacker read or write arbitrary resources on the underlying platform with the user's full privileges, for example memory corruption in the browser process reachable from web content. High (S1) issues let an attacker execute code in the context of other origins, impersonate them or read cross-origin data. Medium (S2) issues let attackers read or modify limited information or are harmful only in combination. Low (S3) issues would normally be higher but have extreme mitigating factors or very limited scope. Two details are worth copying: the individual bugs in an exploit chain keep lower ratings than the chain, and issues in features not enabled by default are handled separately from the fix timelines.
A starting bar for a web or SaaS product
The table below is an NHI Mgmt Group example that adapts these patterns to a typical multi-tenant product. Adjust the classes and examples to your boundaries.
| Class | Definition | Examples |
|---|---|---|
| Critical | Remote, unauthenticated or cross-tenant compromise with broad impact and no meaningful user interaction | Unauthenticated RCE; cross-tenant read of any customer's data; authentication bypass for any account; leaked signing key for tokens |
| High | Crossing a boundary with some precondition: authenticated attacker, specific configuration or ordinary user interaction | Authenticated RCE; privilege escalation to tenant admin; stored XSS in an admin view; SSRF reaching internal services |
| Medium | Limited data exposure or modification, or a flaw useful mainly in a chain | IDOR on low-sensitivity objects; reflected XSS needing a crafted link; missing rate limit enabling account enumeration |
| Low | Defence-in-depth gaps or issues with extreme mitigating factors | Missing security header on a static page; verbose error without secrets; weak configuration only in non-default mode |
| Not a vulnerability | No boundary crossed, or by-design behaviour documented to users | Self-XSS requiring the victim to paste script; administrators acting within their documented powers |
Step three: attach release rules and fix deadlines
A class without a deadline is only a label. Chromium states its prioritisation openly: S0 issues are normally priority P0 and assigned to the current stable milestone, with an aim to deploy the patch to all users in under 30 days; S1 issues are normally P1, with an aim of under 60 days; S2 issues are normally P1 but may move to the next milestone if the fix is complex; S3 issues start at P3. If there is evidence of a weaponised exploit or active exploitation in the wild, the issue becomes P0 regardless of severity, with an objective of 7 days or faster. After 30 days at S3, a low severity bug becomes visible to all Chromium committers so it can be fixed opportunistically.
OWASP ASVS 5.0 asks for the same discipline for third-party components: requirement 15.1.1 (Level 1) is that application documentation defines risk-based remediation time frames for third-party component versions with vulnerabilities, and 15.2.1 that the application only contains components within those time frames. An example structure:
| Class | Before release | After release (fix available to customers) | Who may grant an exception |
|---|---|---|---|
| Critical | Blocks release | [7] days; [72 hours] if exploited in the wild | CISO, with customer communication plan |
| High | Blocks release unless an exception is approved | [30] days | Head of product security |
| Medium | Does not block; scheduled | [90] days | Engineering director |
| Low | Does not block | Next planned refactor or [180] days | Team lead |
The bracketed values are placeholders to set from your own risk appetite and release cadence. Teams that ship continuously can use shorter deadlines than teams shipping installed software with customer-managed updates, but the deadline should run from when the issue is confirmed, not from when someone gets round to triaging it.
Where CVSS, EPSS and KEV fit
Many organisations try to use a CVSS score as their bug bar. FIRST's CVSS v4.0 specification produces scores that indicate the severity of a vulnerability relative to others, and notes that factors such as regulatory requirements and monetary loss are outside its scope. It defines four metric groups (Base, Threat, Environmental and Supplemental), labels scores by which groups were used (CVSS-B, CVSS-BT, CVSS-BE and CVSS-BTE), maps scores to None (0.0), Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9) and Critical (9.0 to 10.0), and says consumers should enrich Base metrics with Threat and Environmental values.
| Input | What it tells you | Use in a bug bar |
|---|---|---|
| Product bug bar class | Impact across your boundaries in your product | Primary rating for defects in your own code |
| CVSS v4.0 (CVSS-BTE where possible) | Comparable technical severity | Required for published advisories and CVE records; a cross-check on the bar class |
| EPSS | Probability of exploitation activity for published CVEs | Prioritising third-party component fixes within a class |
| CISA KEV catalogue | Known exploitation; each entry carries a required action and due date for US federal agencies | Treat any KEV-listed component issue as exploited in the wild |
Map the bar to CVSS loosely rather than mechanically: a cross-tenant data read may score Medium in a base calculation yet be Critical for a multi-tenant business. Record both and explain differences in the ticket. See the CVSS v4 Guide, the EPSS Guide and the CISA KEV Catalogue Guide.
Where identity fits
Identity defects are where generic scoring most often under-rates impact. A leaked token signing key, an OAuth client accepted for the wrong audience, an API key that never expires or a service account with tenant-wide rights may score modestly in a technical calculation but break a boundary for every customer at once. Put explicit identity examples in the bar: token validation flaws, scope enforcement failures and exposed machine credentials should be at least High, and any exposure of a credential that can sign or mint tokens should be Critical with rotation as part of the fix. See the Token and Session Security Guide.
Rolling out a bug bar
- Draft from real history: pull the last year of security bugs from tickets, pentests and bug bounty reports and classify them against the draft bar. Where triagers disagree, the definitions need examples.
- Agree boundaries and deadlines with product owners: deadlines that engineering leadership has not accepted will be ignored.
- Pilot with two or three teams for one release cycle, logging every rating dispute.
- Wire it into tooling: severity fields, due dates calculated from confirmation date, release gates in CI or release checklists, and dashboards.
- Connect intake channels: PSIRT, bug bounty, pentest and internal findings should all use the same classes. See the PSIRT Guide and the Bug Bounty and Vulnerability Disclosure Guide.
- Review twice a year: add examples from disputes, adjust deadlines and retire categories that no longer apply.
- Roll back carefully: if a deadline proves unachievable, change it formally and record why, rather than letting tickets silently breach.
Small and large organisations
A small team can run a one-page bar with four classes, a handful of examples each and deadlines owned by the CTO. A large organisation with several products usually keeps one corporate definition of classes and deadlines and lets each product add its own boundary list and examples, as Microsoft does with separate server, client and hardware tables, so ratings stay comparable across products.
Measuring adherence
- Time to fix by class: median and 90th percentile days from confirmation to fix available, against the deadline.
- Deadline breach rate: open bugs past their deadline, by class and team.
- Release gate overrides: number of releases shipped with an open Critical or High under exception.
- Rating changes: share of bugs re-rated after triage, and in which direction. Frequent downgrades signal pressure on triagers; frequent upgrades signal missing examples.
- Exploited-in-the-wild response: time to fix for issues with evidence of exploitation, against the shortest deadline.
- Repeat classes: the same defect class recurring across releases indicates a missing shared control rather than isolated bugs.
Framework mapping
| Framework | Reference | How a bug bar supports it |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SI-2 Flaw Remediation; SI-2(3) Time to Remediate Flaws and Benchmarks for Corrective Actions | Defined classes and deadlines are the benchmarks; time-to-fix metrics are the measurement |
| NIST SP 800-53 Rev. 5 | RA-5 Vulnerability Monitoring and Scanning; RA-7 Risk Response; SA-11 Developer Testing and Evaluation | Consistent rating of findings from testing; risk response for exceptions |
| NIST CSF 2.0 | ID.RA-05; ID.RA-06 | Impact and likelihood inform prioritisation; responses chosen, tracked and communicated |
| OWASP ASVS 5.0 | 15.1.1; 15.2.1 | Documented risk-based remediation time frames for components, and compliance with them |
| FIRST CVSS v4.0 | Qualitative severity scale; CVSS-BTE nomenclature | Comparable severity for advisories alongside the product class |
Common failure patterns
- Using CVSS base scores as the bar: base scores ignore your boundaries and exploitation evidence, so business-critical flaws like cross-tenant reads can land as Medium.
- Deadlines that start at triage: bugs left untriaged never breach. Start the clock at confirmation and set a triage deadline as well.
- No "exploited in the wild" override: a Medium bug under active exploitation needs the fastest response, as Chromium's P0 rule recognises.
- Rating the chain, not the parts, or the parts, not the chain: decide how chains are rated; Microsoft rates a combinable issue at the higher class, while Chromium keeps component bugs lower than the chain.
- Different bars per intake channel: pentest, bug bounty and internal findings using different scales make metrics meaningless.
- Exceptions without expiry: an approved delay that never ends turns the bar into a suggestion.
Practitioner checklist
- Write down your product's security boundaries before defining classes.
- Define four or five severity classes with at least three concrete examples each, including identity and token examples.
- Attach a release rule, a fix deadline and an exception approver to every class.
- Add an exploited-in-the-wild override with the shortest deadline.
- Record CVSS v4.0 alongside the bar class for anything that will become an advisory or CVE.
- Use the same bar for PSIRT, bug bounty, pentest and internal findings.
- Start deadlines at confirmation and set a separate triage deadline.
- Track time to fix, breach rate, gate overrides and rating changes by class.
- Review the bar twice a year using disputed ratings as new examples.
Standards and references
- Microsoft MSRC: Microsoft Vulnerability Severity Classification for Windows (SDL Bug Bar)
- Microsoft MSRC: Microsoft Security Servicing Criteria for Windows
- Chromium: Severity Guidelines for Security Issues
- FIRST: CVSS v4.0 Specification Document
- CISA: Known Exploited Vulnerabilities Catalog
- OWASP: Application Security Verification Standard 5.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Remediation SLAs and Vulnerability Exceptions Guide · CVSS v4 Guide · PSIRT Guide · Vulnerability Prioritisation Guide