How do you turn Nessus or ACAS scan results into a POA&M?

Import the scan, normalize its findings onto a single definition of what counts as one finding, correlate them to the controls and checklist items they bear on, and promote the ones that need remediation into POA&M items that keep a link back to the scan that produced them. The POA&M then exports to eMASS, upserting on the external identifier so a second export does not duplicate open items.

What scan formats does CertiField import?

ACAS and Nessus, plus SAST and DAST output, container and dependency scanners including Grype and Trivy, secret scanning from Gitleaks, static analysis from Semgrep and SonarQube, and CycloneDX and Dependency-Check SBOMs. Results arrive by manual upload or straight from a GitHub or GitLab pipeline.

What happens when a scan is re-run and a finding is fixed?

A clean run is recorded rather than discarded, which is what allows previously-open findings to show as resolved. If a clean scan is thrown away as a suspected schema error — which some tools do — the last dirty scan stays the newest data point forever and nothing ever closes.

Vulnerability management

Scan results are evidence. Treat them that way.

An ACAS export is not a POA&M, and the gap between them is where most programs lose a week every cycle. The work is correlation — which control does this bear on, is it already known, and has anyone already judged it.

ACAS · Nessus
SAST · DAST
SBOM
CI pipeline ingest
eMASS POA&M export

Ref: V-01
Kind: Normalize
Counted per: advisory, not occurrence

One definition of "a finding", across every source.

Findings arrive from ACAS and Nessus, from SAST and DAST, from container and dependency scanners, each with its own idea of what constitutes one issue. CertiField normalizes them onto a single definition so the number on a dashboard, the number in the list and the number in the export are the same number.

That sounds obvious until you have watched a project report one count on a trend line and a different count in the list directly above it. Counting per advisory rather than per occurrence is the choice that matters, because the advisory is what gets fixed.

Ref: V-02
Kind: Correlate

Connect the finding to the control it bears on.

A finding that nobody has mapped to a control is a finding nobody can act on in RMF terms. CertiField correlates scan findings to the controls and checklist items they affect at import, so the mapping is recorded rather than re-derived from a filename at review time.

When the scan re-runs, affected items reopen on their own. A clean run is recorded, not discarded — storing the clean scan is what makes previously-open findings show as resolved.

Correlated on import to controls and checklist items
Re-scan reopens what regressed, and closes what was fixed
False-positive decisions survive the next upload rather than dying with the row
Secrets never stored — Gitleaks matches are redacted before the payload is kept

Ref: V-03
Kind: Remediate
Sync: two-way with Jira

Into POA&M, and back out to eMASS.

Findings that need remediation become POA&M items with milestones, owners and dates, keeping the link back to the assessment and the scan that produced them. Because the remediation work itself usually lives in Jira, CertiField syncs it two ways rather than asking engineers to update a second tracker they will forget about.

Export to eMASS upserts on the external identifier eMASS assigned, so a second export updates the item your reviewers already have open instead of raising a new one beside it.

Bring a recent scan Scanner and SBOM integration

Next step

See what your RMF process looks like when the package keeps up with the system.

Request a demo Explore the product