LEARN. PRACTICE. GROW.Concept and mechanism
Software security starts with requirements and design boundaries. Identify assets, untrusted inputs, sensitive operations, and abuse cases before implementing integrations. Update analysis when new partners, dependencies, or data uses appear. SAST, DAST, and SCA produce different evidence: code, runtime behavior, and components are not the same assessment object. A clean result in one technique does not demonstrate coverage of the others. In a query, separate values from instructions using parameters and handle structural elements through appropriate design and validation. Encrypting the database connection does not correct unsafe SQL construction.
Guided application
The pipeline also has identities, secrets, and artifact-publication capability. A credential committed to source can persist in clones and logs; remove exposure, rotate or revoke the token, and correct secret delivery. For AI-assisted code, apply the same review and test criteria to the actual artifact. A similar library name does not prove equivalent origin. Confirm dependencies, provenance, and affected authorization paths before promotion. SSDF 1.1 is the final version used in this pass; the inspected NIST list distinguishes proposed 1.2, still a draft. Practices guide work and supplier communication without turning a generic compliance statement into proof that this release meets every requirement.
A hotfix passes functional tests but adds a dependency from a different origin: review remains necessary before approval.
Common pitfalls
Security only after go-live; one tool treated as total coverage; credential removed from commit treated as revoked; AI treated as review exemption.
Related topics: Governance, ethics, and risk decisions · Assets, data, and decommissioning
Promote a known artifact with matching requirements and evidence, including dependencies.
Reference: Secure Software Development Framework 1.1 · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29