When CISA issued BOD 26-04 on 10 June 2026, it set remediation clocks from four facts: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether exploitation can be automated, and whether the impact is partial or total control. It also says the clock is measured in calendar days and starts at a defined trigger. A pen test report deserves the same treatment. A finding without a clock, an owner and a definition of done is a paragraph in a PDF.
This post is about the step after you read the report: getting each finding into the tracker in a form that engineers will pick up and that an auditor or customer can follow later.
What's affected
Every team that has received a penetration test report and now holds a list of findings with a severity label each. The same method works for DAST output and internal reviews.
How to check if you're exposed
Open your tracker and look at the last test's findings. You have a problem if any of these are true:
- Findings live only in the PDF or a spreadsheet.
- A ticket says "fix XSS" with no URL, parameter or request.
- Nobody is named as owner, or the owner is "security".
- There is no due date, or the due date was set by the vendor's severity alone.
- Closed tickets have no proof that the fix was verified.
What to do now
- Make one ticket per root cause, not per instance. Five endpoints that skip the same authorization check are one ticket with five affected URLs. Ten reflected cross-site scripting findings caused by one missing output encoder are one ticket. Link each ticket to the report ID of every finding it covers.
- Keep the report's rating and add your own. The FIRST CVSS 4.0 specification (version 1.2, 18 June 2024) maps scores to None, 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). It also asks that the nomenclature (CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE) be shown wherever a score appears. Record the vendor's score as given, then record your own priority after you consider exposure and data.
- Set priority from exposure and impact. Use the table below as a starting point and write it into your policy.
- Use a fixed ticket template. Copy the one below into your tracker.
- Name an owner and a due date at creation. The owner is the engineering team that owns the code, not the security team. The due date comes from your remediation policy.
- Add a verification step. The definition of done is not "merged". It is "retested by the vendor, or by a named internal reviewer with a test case that now fails safely".
- Open a short triage meeting within a week of the report. Thirty minutes, one engineering lead per affected service, one person from security. Leave with every ticket owned and dated.
- Track exceptions as tickets too. If a fix is deferred, record who accepted the risk, the compensating control and the review date.
Severity to priority
| Report severity | Reachable from the internet? | Suggested handling |
|---|---|---|
| Critical | Yes | Drop other work, fix or mitigate within days, notify leadership |
| Critical | No (internal only) | Next sprint, mitigate sooner if the data is sensitive |
| High | Yes | Current sprint, owner named in triage |
| High | No | Next one or two sprints |
| Medium | Either | Planned backlog, due date from policy |
| Low and informational | Either | Batch into hardening work, close with a note if you accept the risk |
The numbers here are a starting point. Your policy and your customers' contracts set the real limits, so write them down once and apply them consistently.
Ticket template
Title: [Service] Short description of the weakness (report ID PT-07)
Severity (vendor): High, CVSS-B 8.1
Priority (ours): P1, internet-facing, customer data
Affected: POST /api/v2/invoices/{id}, GET /api/v2/invoices/{id}/pdf
CWE: CWE-639
Report finding IDs: PT-07, PT-09
Reproduction: steps and requests from the report, attached
Expected fix: authorize the invoice against the caller's tenant on every route
Owner: billing-api team, named engineer
Due: date from policy
Verification: vendor retest, or test case added to CI that fails if tenant A reads tenant B
Status history: opened, in progress, fixed, verified, closed
That ticket names CWE-639, broken object level access, which is the usual reason two different routes belong in one ticket.
How to avoid this trap
- Ask the vendor for findings in a CSV or JSON export in addition to the PDF, so tickets can be created in bulk without retyping.
- Put the report's finding ID in every ticket title. That is the thread an auditor follows from report to fix.
- Add a regression test for each fixed finding. A fix that is not tested tends to come back in the next refactor.
- Do not let the vendor's severity be the only input. They rarely know which of your services are internet-facing or hold the most sensitive data.
Why it matters
Reports are written for the reader who wants to understand risk. Tickets are written for the person who must change code on Thursday. The translation is where most remediation programs slow down.
BOD 26-04 is useful here even if you are not a federal agency. It shows a rule that ties urgency to facts about the asset, not to a label alone. Exposure and data sensitivity belong in your own scheme, and your tracker should record the reasons for each priority so the decision can be explained later.
Try it yourself
Take the three most severe findings from your last report. For each one, write the ticket using the template above and set a priority from the table. Then ask: if the engineer who picks it up never read the PDF, could they fix it from the ticket alone?
Click through it at your own pace, or open it full screen.
Quick check
Why combine findings that share a root cause into one ticket?
One code change fixes them all, and one verification covers them. Separate tickets split the work and let some instances stay open by accident.
What should "done" mean for a pen test finding?
Done means verified, either by the vendor's retest or by a named reviewer with a test that proves the weakness is gone. Merged code alone is not proof.
Who should own a ticket?
The engineering team that owns the affected code, with a named engineer. Security supports and verifies.
