Build assurance across code, components, and suppliers

Static application security testing, or SAST, examines code or related representations without exercising the running application. It can identify unsafe patterns early, but a reported path may need developer review to establish reachability and impact. Keep findings linked to the relevant revision and build. A clean result covers only the rules, languages, and code included in that assessment.

Dynamic application security testing, or DAST, observes a running application through its interfaces. It can reveal behaviour that depends on configuration and integration, but only for the routes, identities, and interactions actually exercised. Use representative synthetic data and authenticated workflows where appropriate. Combine static findings, dynamic results, and manual reasoning; none of them independently proves that all business-logic or authorisation requirements are satisfied.

The Software Assurance Maturity Model, or SAMM, helps an organisation evaluate and improve software security activities across the lifecycle. It is a framework for programme development, not a scanner or a certificate that a particular build is safe. Use it to identify gaps in areas such as security requirements, design review, verification, governance, and operational feedback.

Choose improvements that address observed failures. If the same access-control defect repeatedly reaches production, add clearer design requirements, developer guidance, and targeted regression checks rather than merely buying another scanner. Assign an owner and evidence of adoption for each improvement. Review whether the change reduced recurrence and whether teams can sustain it within normal development and release work.

A software bill of materials, or SBOM, records components and their relationships or versions for a software artefact. Software composition analysis, or SCA, helps identify dependencies and match them with known issues. The inventory and the analysis complement each other: an SBOM is not itself a guarantee of security, and a dependency match still requires version, applicability, deployment, and exposure review.

Extend this reasoning to suppliers that build, host, or maintain services. Establish ownership of assessment, update delivery, notification, access, evidence, and end-of-support planning. Include transitive dependencies and build inputs where relevant, not just the product name on a purchase order. Request appropriate assurance and verify important claims, while using procurement or legal colleagues to interpret contractual obligations and residual-risk decisions.