Managing Recurring Low-Severity Findings in Audits and Pen Tests

By Cymantis Labs

In cybersecurity and compliance, not every finding carries the same weight. While critical and high-risk vulnerabilities demand immediate attention, recurring low-severity findings often appear across audits and penetration tests. These can create unnecessary noise if not addressed consistently and strategically.

This post goes deeper into why these issues recur, how to reason about residual risk, and what to say (and show) to auditors so your teams can focus on material risk without sacrificing transparency.

Why Low-Severity Findings Recur

Typical root causes:

Legacy constraints – Older app stacks or third‑party components where upgrades are scheduled but not immediate.
Architecture choices – Intentional design tradeoffs (e.g., public APIs with strict read‑only semantics) that are low exploitability.
Compensating controls – WAF rules, HSTS, TLS‑only transport, RBAC, and monitoring already reduce likelihood/impact.
Business context – Data involved is non‑sensitive, constrained, or requires authentication/authorization to access.
Operational windows – Changes are bundled into planned releases or maintenance cycles per change management policy.

These drivers don’t excuse risk—they frame it. Your job is to document that framing rigorously.

Key Concepts (Fast Primer)

Inherent vs. Residual Risk: Inherent = risk before mitigations. Residual = risk after mitigations/compensating controls.
Likelihood vs. Impact: Keep separate. Many repeat findings are low likelihood due to strong mitigations (e.g., TLS, authN/Z) even if the theoretical impact could be higher.
Exploitability: Combine preconditions (auth required? specific roles? user interaction?), technical complexity, and controls that interrupt kill chains.
Evidence-Based Risk: Assertions must be backed by logs, configs, and tickets—not opinion.

The One-Liner That Scales

Use a structured, reusable response to document status, residual exposure, and mitigation:

“This control gap was previously logged as [ID]; scope has since changed and residual exposure is limited to [system/endpoint]; mitigations [X, Y] reduce exploitability to [likelihood], and we accept the remaining risk through [date] pending [fix/retirement].”

Template Fields

Field	Description	Example
[ID]	Risk register/POA&M/Jira/ServiceNow tracker key	`ARS‑PEN‑6‑2024`
[system/endpoint]	Bounded surface (URI, host, service, feature)	`/mb/api/v2/search`
[X, Y]	Mitigations: TLS/HSTS, WAF rules, RBAC, rate limits, alerts	`WAF‑1234, HSTS enabled`
[likelihood]	Post‑mitigation risk level	`Low` / `Unlikely`
[date]	Risk acceptance expiration	`2025‑12‑31`

Quality bar: If you can’t link to at least one evidence artifact (change ticket, config PR, WAF rule, dashboard), the one‑liner isn’t ready.

Decision Guide: Remediate Now vs. Accept Temporarily

Remediate now when any applies:

Sensitive data exposure (e.g., PHI/PII) or auth bypass.
Exploit requires no auth or trivial preconditions.
Widespread blast radius (multi‑tenant, cross‑system impact).
Clear policy/regulatory noncompliance.

Consider temporary acceptance when all apply:

Strictly bounded scope (one endpoint, isolated host, read‑only path).
Strong compensating controls demonstrably lower likelihood.
Data sensitivity is low; no privilege escalation path.
Fix is scheduled with owners, funding, and date.

Evidence Package (What Auditors Want to See)

Tracking: Link to risk record/POA&M item with status and owner.
Mitigations: Links to WAF rules, header configs (HSTS, Secure, SameSite), RBAC policies, and network ACLs.
Monitoring: Saved searches/dashboards/alerts (IDs and screenshots) for anomaly detection.
Plan: Dated change ticket/PR for the permanent fix.
Review cadence: Quarterly re‑validation note or expiration date.

Pro tip: attach a 1‑page Risk Acceptance Memo (template below) to close the loop.

Templates You Can Copy

1) Risk Acceptance One‑Pager (Memo)

Title: Risk Acceptance – [ID] [Finding Name]
Owner: [Team/Name]    Reviewer: [Security/Compliance]    Expiry: [YYYY‑MM‑DD]

Scope & Context:
- Affected system/endpoint: [exact]
- Data classification: [Public/Internal/Confidential]
- Precondition(s): [Authentication/Role/Specific flow]

Mitigations in Place:
- Transport & session: [TLS1.2+, HSTS, Secure/SameSite cookies]
- Access control: [RBAC policy link, rate limits]
- Detection: [SIEM search + alert ID]
- Other: [WAF rule IDs, gateway allow‑lists]

Residual Risk Assessment:
- Likelihood: [Low/Unlikely]
- Impact: [Low/Moderate]
- Justification: [2–3 lines]

Plan & Date:
- Permanent fix: [ticket/PR link]
- Target date: [YYYY‑MM‑DD]
- Re‑validation: [quarterly/monthly]

Approvals:
- Security: [name/date]
- Product/Business: [name/date]
- Compliance: [name/date]

2) POA&M Tracker Example

Field	Value
ID	`ARS‑PEN‑4‑MB‑CORS`
Weakness	CORS allow‑list incomplete on `/mb/api/v2/search`
Impact	Low (read‑only, no credentials)
Mitigations	API gateway origin allow‑list; header hardening; no cookies/credentials
Status	Risk Accepted (time‑bound)
Milestone	Origin allow‑list rollout to all endpoints
Planned Completion	`2025‑12‑31`
Evidence	`WAF‑1234`, `GATE‑PR‑998`, `Dash-Splunk‑MB‑Cors‑Mon`

3) Reusable Response Snippets (Common Cases)

CORS (read‑only, no credentials):

Previously logged as PEN‑4‑MB‑CORS; residual exposure limited to /mb/api/v2/search; mitigations (gateway origin allow‑list, Access‑Control‑Allow‑Credentials: false, response header hardening) reduce exploitability to Low; accepting residual risk through 2025‑12‑31 pending allow‑list rollout.

Cookie without Secure on legacy path (TLS‑only site, HSTS):

Previously logged as PEN‑2‑COOKIE‑SECURE; residual exposure limited to JSESSIONID on ClaimReopening_en; mitigations (TLS‑only, HSTS, short session TTL) reduce exploitability to Low; accepting residual risk through 2025‑11‑30 pending session library upgrade.

Authenticated read of non‑sensitive artifacts (e.g., certificate metadata):

Previously logged as PEN‑6‑CERT‑DISC; scope limited to authenticated users viewing non‑sensitive certificate metadata; mitigations (RBAC, audit logging, no PII/PHI, rate‑limits) reduce exploitability to Low; accepting residual risk through 2025‑09‑30 pending granular object‑level policy.

⚠️ Boundaries: Do not use these for unauthenticated data exposure, stored XSS, IDOR that bypasses authorization, or anything enabling privilege escalation.

Monitoring: Example SPL/Queries (Illustrative)

CORS endpoint watch (volume & referrer anomalies):

index=proxy OR index=api sourcetype=httplog uri_path="/mb/api/v2/search"
| stats count by src_ip, http_method, status, cs_referer
| where http_method!="GET" OR status>=400

Cookie policy drift:

index=web sourcetype=nginx "Set-Cookie"
| rex field=_raw "Set-Cookie: (?<cookie>\w+)="
| stats latest(_raw) as sample by cookie
| search cookie=JSESSIONID NOT "Secure" NOT "SameSite"

Certificate metadata access spikes (auth required):

index=app sourcetype=app_audit action=generate_certificate user!=service_*
| timechart count by user span=1h
| where count > 3*avg(count)

Governance & Process (Make It Boring, Predictable)

RACI:

Responsible: Feature owner / service team.
Accountable: Product or Engineering lead.
Consulted: Security, Privacy, Compliance.
Informed: Program/PMO.

Cadence:

Risk acceptance expires in ≤ 6–12 months unless renewed with justification.
Quarterly review of all accepted risks; auto‑escalate if past due.

KPIs:

Count of low‑severity items open > 180 days.
Percentage with complete evidence package.
Mean time to close (not just accept).

Framework Mapping (Orientation Guide)

Use these as pointers when aligning to common frameworks (adjust to your environment):

Risk & Vulnerability: RA‑3 (Risk Assessment), RA‑5 (Vuln Monitoring), SI‑2 (Flaw Remediation), CA‑5 (POA&M).
Configuration & Change: CM‑3 (Change Control), CM‑6 (Config Settings).
Boundaries & Sessions: SC‑7 (Boundary Protection), SC‑8 (Transmission Confidentiality/Integrity), SC‑23 (Session Authenticity).
Logging & Review: AU‑2 (Event Logging), AU‑6 (Audit Review).

Your POA&M should reference these control families and link to evidence.

Case Studies (Putting It All Together)

Case 1: CORS on Search API (Read‑Only, No Credentials)

Finding: Wildcard origins permitted on /mb/api/v2/search.
Context: Endpoint returns public search results; no cookies; GET only.
Mitigations: API gateway origin allow‑list in progress; response headers prevent credentialed cross‑site requests.
Residual Risk: Low – exploit staging is limited and provides no new privilege.
One‑liner: See snippet in Templates.

Case 2: Cookie `Secure` Flag Missing on Legacy Flow

Finding: JSESSIONID occasionally set without Secure on ClaimReopening_en.
Context: Site enforces TLS and HSTS; short session lifetimes; no mixed content.
Mitigations: Library upgrade scheduled; WAF enforces HTTPS redirects.
Residual Risk: Low – transport protections materially lower exposure.
One‑liner: See snippet in Templates.

Case 3: Authenticated Certificate Metadata Visibility

Finding: Authenticated users can view other users’ certificate metadata (no PII/PHI).
Context: Requires login; metadata only, no secrets; downloads watermarked and logged.
Mitigations: RBAC restricts roles; rate‑limits; audit alerts on anomalies.
Residual Risk: Low – no escalation path or sensitive data exposure.
One‑liner: See snippet in Templates.

Not a candidate for acceptance: Stored XSS on file upload or IDOR that bypasses object‑level authorization—fix immediately.

Handling Auditor Pushback (FAQ)

Q: If this was “fixed” last year, why is it back? A: Scope changed; the previous fix removed exposure for most endpoints. Residual exposure is now restricted to [endpoint], with controls [X,Y]. Evidence attached.

Q: Why classify as Low? A: Likelihood is Low given [auth, RBAC, TLS, WAF]; impact is Low due to [no PII/PHI, read‑only, no escalation]. Our risk matrix and evidence support this rating.

Q: When will it be fully resolved? A: Scheduled under change [ticket/PR] with target date [YYYY‑MM‑DD]. Acceptance expires on that date unless renewed with justification.

Final Thoughts

Low‑severity issues aren’t meaningless—they represent managed, measured risks. By applying a consistent response model, packaging evidence, and running a crisp governance cadence, you:

Preserve focus on material risk.
Communicate clearly with auditors and leadership.
Reduce backlog thrash and re‑work across audit cycles.