DevSecOps Extra Supporting Automation

Beyond the baseline evidence pipeline, a few additional automated checks can strengthen your ATO posture. These additional items may be considered optional and not required, at least initially, though they tend to be beneficial and relatively easy. Many of them also help satisfy Application Security and Development SRG/STIG requirements — for example, automated test code coverage and vulnerability scanning (V-222515, V-222624). Agentic AI tools like Claude Code, OpenAI Codex, or Cursor can help with more rapidly adding test coverage and addressing the vulnerability findings found by scanning described below.

[ESA-1] Implement container image signing

Image signing proves provenance: that the image you deploy is the exact image your pipeline built, unaltered in transit or in the registry. It maps primarily to integrity controls (NIST SP 800-53 SI-7, "Software, Firmware, and Information Integrity," and its code-authentication enhancements).

On a curated DevSecOps platform this is mostly an integration task rather than something you build. The container registry typically provides image-signing / content-trust support, and the cluster's admission control can be configured to verify signatures and refuse unsigned images at deploy time. Your work is to wire signing into the deploy step of the pipeline (see [EVID-1]) and to turn on signature verification at admission. As a concrete example, cosign can sign images during deployment and is one of the signing methods the Harbor container image registry supports. Because the platform carries the heavy machinery, this is usually a light lift — but in higher-impact environments the expectation to sign artifacts end-to-end grows, so confirm the requirement for your impact level early.

[ESA-2] Implement anti-virus scanning with ClamAV

Anti-virus / malicious-code scanning addresses NIST SP 800-53 SI-3 (Malicious Code Protection): mechanisms at system entry and exit points that detect malicious code and are kept current as new signatures are released. ClamAV is a practical open-source choice, and the Iron Bank pipeline-runner containers already bundle it, so you can run it from the same runner as your other scan stages like OpenSCAP scanning.

Add a scan stage that, for each image, refreshes the signature database (freshclam) and then scans the built image's filesystem before it is delivered for deployment. Two practical notes from doing this:

Emit a bounding statement with every clean result. Record the loaded signature count and engine version alongside the detection count, so that a 0 reads as "scanned against a current signature set," not "scan failed or empty." Produce both a structured (JSON) record for machines and the human-readable scan summary.
Give the scanner a writable database location. ClamAV needs to write and refresh its signature database to a working directory; in a locked-down container that path is often not writable by default, which fails the scan stage until you point it at a writable temporary location.

Mind the scope of this evidence: it covers the delivered container images, not source code or data your application ingests at runtime. That runtime malicious-code protection is typically a host-level capability inherited from the hosting platform.

[ESA-3] Integrate Static Application Security Testing and Secret Scanning

Unlike CVE/dependency scanning (which only finds known vulnerabilities in third-party components), static application security testing (SAST) inspects your own source code for flaws. You'll likely need to run multiple tools to cover a real multi-language codebase—a suite of language-specific analyzers whose output you normalize into a common format. In our pipeline this meant, depending on the language:

clang-tidy and Cppcheck for C/C++
Bandit for Python
Semgrep for multi-language coverage
Roslyn analyzers plus Security Code Scan for .NET / C#
ESLint (with the eslint-plugin-security and eslint-plugin-no-secrets plugins) for JavaScript / TypeScript

All static analysis results can be normalized into SARIF (Static Analysis Results Interchange Format), a standardized JSON format for consistent processing by machines or humans. See the official SARIF site for details.

SAST tools can often check for both security and non-security (coding style, etc.) issues, and you can configure what they scan for. Security issues are the most important for ATO and should be tracked specifically and addressed where possible. Other findings may be useful as further support of good coding practices but may not be as critical for initial authorization.

Closely related is secret scanning — scanning your repositories and built images for credentials (API keys, tokens, certificates) that were accidentally committed. It looks for exposed credentials rather than code-logic flaws, but it is convenient to run in the same pipeline; a dedicated secret scanner (for example, Trivy's secret-scanning mode) covers it, and secret scanning is often included in many SAST tools as well. Managed platforms can cover this ground too — for example, GitHub provides CodeQL and other security-scanning features that perform this kind of SAST and secret detection.

[ESA-4] Integrate automated test coverage

Code coverage is part of developer testing evidence (it maps to SA-11, "Developer Testing and Evaluation"). Emit a coverage report from your existing test suite and collect it alongside the rest of your evidence. Common coverage tools by language include:

gcov / lcov for C/C++
Coverage.py for Python
Coverlet for .NET / C#
Istanbul (nyc) for JavaScript / TypeScript (also available through Vitest via @vitest/coverage-istanbul)

[ESA-5] Implement fuzz testing

Fuzz testing exercises your code with malformed or random inputs to surface crashes and edge-case failures that ordinary tests miss (fuzz testing can be important for helping demonstrate your application can handle malformed adversarial input). Report how much fuzzing you do as part of your authorization package. Common fuzzing tools by language include: