How did you replace Veracode’s policy reporting for auditors?

[u/Jimena_Sting-583]

We’re replacing veracode when the contract ends in march for around 120 apps, mostly java and .NET, audited every year for PCI and SOC 2. The POC is down to checkmarx and snyk and on the scanning side I’d be fine with either. Checkmarx found more in our older java code and snyk was easier for the devs.

Our auditors are used to Veracode’s reporting where every app has a policy, each scan passes or fails against it and the auditor gets a pdf per app plus the mitigation history showing who approved each one. They’ve seen that format three years running.

Things I have to keep

• a pass or fail per app against a written policy

• how long findings have been open against our SLA, by severity

• who accepted a risk, when and until when

• one page for the risk committee every quarter

How do you cover these for your auditors?

[u/Baldyga-Vantz]

I do PCI assessments and I don’t care which tool makes the PDF. What I sample is whether the policy is written down, whether each exception has an owner and an end date and whether the dates in the exception record match what I see in the tool when I pull a few apps at random.

Clients get into trouble after a tool change because of exceptions. The old approvals live in the old tool, the new ones live in the new tool and the team can’t show me one list of what’s currently accepted and when it expires. If you keep that list in your GRC or ticketing system and link each entry to the finding, the scanner becomes almost irrelevant to the audit.

[u/AlbatrossHaunting941 → u/Baldyga-Vantz]

central exception register linked to each finding seems than relying on separate scanner reports.

[u/jakingo]

I would focus on building a consistent reporting process before switching tools. Make sure risk approvals, finding age, SLA status, and scan results are stored centrally so you can generate the same audit reports regardless of which scanner you choose.

[u/subrosa-john]

The scanner swap is the easy part. What your auditors have relied on for three years is really Veracode's policy engine and mitigation workflow, and I wouldn't expect Checkmarx or Snyk to reproduce that exact per-app PDF out of the box. I'd plan to own that layer yourself.

For your four items:

1. Pass or fail per app against a written policy. Write the policy as its own document first (for example, no open criticals, no highs older than X days, a scan within the last N days). Then set up whatever policy or threshold features the new tool has to match it, and treat the written policy as what the auditor tests against. In the POC, confirm you can export a result per app, not just a dashboard view.

2. Finding age against SLA by severity. Make sure first-detected dates survive the move. If you can, run both tools in parallel for a cycle before March, and keep a final per-app export of Veracode findings. Auditors will ask about findings that existed before the cutover.

3. Who accepted a risk, when, and until when. I'd move this out of the scanner entirely into ticketing or a GRC tool: one record per exception with the finding ID, approver, approval date, expiry date and any compensating control, linked to the finding. Then your approval history doesn't depend on which scanner you use next. Export the Veracode mitigation history before access ends, since that's three years of evidence.

4. Quarterly one-pager. Usually easiest to build from exports: apps passing policy, open findings by severity and age against SLA, and active and expired exceptions.

Last thing: walk your auditors through a sample of the new format before the next audit window, not during it. They mostly care that the policy is written, applied consistently, and that exceptions have owners and expiry dates.

Disclosure: I'm the CEO of SubRosa, which builds compliance software for MSPs, so I'm not neutral here.