Run static application security testing and dependency or container scanning in the CI pipeline so insecure patterns, hardcoded secrets and vulnerable packages show up while the code is still changing. Generate the SBOM from the built image as a build artifact and add an SBOM support report with level of support and end-of-support dates for the major components. Write a verification protocol for each security requirement and each threat control.
On the map: SAST and container scanning in CI. SBOM with support dates. Cyber verification protocols.
Rows are disciplines, columns are stages 1 to 8. Select a square to open that task.
Back to the full map
Agree with engineering which scanners gate a merge, and ask regulatory which SBOM fields the eSTAR needs. Support dates are cheap to record now and slow to research at submission.
At the first build sprint. A poorly supported dependency found at submission time forces a fork, a rip-out or a strained mitigation. Found early it is a routine swap.
Language dependencies and their transitive dependencies, system packages and the OS layer of the container. Cloud services and compilers are usually left out because the manufacturer cannot upgrade them. Development-only packages stay out so customer scans do not raise false alarms.
Look up end-of-support and level of support for the components that would be hard to replace quickly, such as the base image, the language runtime and the main frameworks. Record the rest as indeterminate with a one-line rationale.
Critical and uncontrolled high vulnerabilities, and any applicable entry on the CISA Known Exploited Vulnerabilities list. Lower findings get a written disposition covering exploitability, device impact and compensating controls.
See the open positions and apply.