The job to be done
Prevent an application-specific failure and give developers a fix they can verify.
Application and software supply-chain security combines complementary controls: static and dynamic testing, software composition analysis, secrets detection, machine-readable inventory, build integrity, and a posture layer that correlates those signals. A web application firewall can reduce exploitability of some HTTP classes; it does not fix first-party flaws, inventory transitive open-source software, rotate leaked tokens, or prove build provenance. NIST's Secure Software Development Framework treats secure development as lifecycle practices, not a single tool class.
What goes in
- Architecture and source code
- Dependencies and build artifacts
- Running application behavior
What should come out
- Actionable findings and fixes
- Dependency and provenance evidence
- Security checks in the delivery process
Inside the segment
These capabilities answer different questions. Use the distinction to define the work before assembling a shortlist.
Static application security testing
Inspect source, bytecode, or binaries at rest for weakness classes such as injection, memory safety, and authorization flaws before the application runs.
Boundary: Static application security testing (SAST) is not runtime confirmation and is not open-source CVE matching. Quality platforms and AppSec SAST can overlap; a quality gate is not automatically an AppSec program.
Dynamic application security testing
Exercise a running web application or application programming interface, typically in a non-production environment, to find issues that appear only at runtime.
Boundary: Testing a running application generally does not by itself establish precise source-line ownership, though some integrations may correlate findings to source. Official GitLab documentation warns not to run DAST against production. It is not a substitute for embedded or protocol testing.
Software composition analysis
Identify direct and transitive third-party and open-source packages, often including licenses and malware signals, so known component flaws can be reviewed.
Boundary: Software composition analysis (SCA) does not find first-party logic bugs. A container CVE list is not function-level reachability. Unused-but-shipped components may still belong in an inventory even when reachability hides them from developers.
Secrets detection
Find hard-coded keys, tokens, and unstructured credentials in repositories, pull requests, and sometimes tickets or logs before they spread.
Boundary: Detection is not secret rotation or vault operations. Push protection and custom patterns may be separate entitlements from code scanning, as with GitHub Secret Protection versus GitHub Code Security.
Software bill of materials
Produce a formal component inventory and relationships, commonly in SPDX or CycloneDX, so later disclosures can be matched to what was actually shipped.
Boundary: A software bill of materials (SBOM) is not a vulnerability scanner by itself. Unsigned component inventory can still be useful for matching later disclosures. Signing and attestations can strengthen integrity and origin evidence but are not universal prerequisites for a useful SBOM. Generation without ingest, retention, component matching, completeness notes, and distribution has limited operational use.
Application security posture management
Correlate scanner results, ownership, policy, and backlog so residual risk is routed rather than sitting in disconnected tool queues.
Boundary: Application security posture management (ASPM) does not replace engines. Quality still depends on inputs. Buying another dashboard is not a prerequisite for a shared triage process.
Signing and provenance
Attach signed assertions about an artifact, its build process, and source inputs so operators can verify digest, signer identity, and policy before admission.
Boundary: A signature does not prove the source is free of bugs or that the builder was uncompromised. Supply-chain Levels for Software Artifacts (SLSA) is a build-integrity framework, not a scanner. A web application firewall sits beside this chain, not inside it.
How the work flows
Author with early feedback
Give developers static testing, composition analysis, secrets detection, and license policy in the editor and pull request. The goal is fast, language-accurate feedback on code the team actually writes, not a weekly portal dump.
Control the merge
Use branch rules to require scan status, dependency review, and configured quality or security gates before merging. Configure secret push protection or an equivalent pre-receive control separately for supported patterns. Test it with a vendor-approved nonfunctional pattern or configured synthetic rule. Route existing findings for remediation without resetting their history.
Build inventory and integrity
Use reproducible or isolated builders. Generate an SBOM from lockfiles or the built artifact, sign the image or binary, and attach provenance. Record known completeness gaps instead of implying the SBOM is exhaustive.
Admit artifacts through the registry
Apply policy on what may be pulled, including package firewalls where used. Scan images with composition analysis. Treat admission control as distinct from builder isolation and from source SAST.
Test running apps before production
Run DAST or interactive testing against review apps or staging only. Keep production URLs out of scope. Confirm at least that seeded runtime issues appear and that findings can be owned back to a service.
Release evidence and operate
Store signed SBOM and provenance with the artifact. Monitor new CVEs against retained inventories. ASPM or an equivalent process tracks residual risk and owners. Web application firewalls and runtime sensors sit beside this chain; a blocked exploit does not mean the code was fixed.
The environment changes the question
Use these scenarios to adapt the evaluation to your organization. They describe operational concerns, not a determination of compliance.
Finance ↗
A payments team must preserve review decisions, exception history, and reproducible release evidence. Code and dependency metadata can be sensitive even when analysis is binary-only or self-managed tools still contact cloud services.
Evaluate: Evaluate data flows, residency, and exportable evidence before assuming a SaaS scanner is acceptable for the application under review.
Utilities ↗
Long-lived firmware and supplier-controlled systems make component inventory, update provenance, and maintained toolchain evidence more valuable than a one-time web scan.
Evaluate: Test on representative isolated systems. Web DAST is not a substitute for embedded or protocol assurance.
Manufacturing ↗
Automotive and factory software often includes C and C++, cross-compilation, proprietary software-development kits, firmware, and safety-related change review.
Evaluate: A scanner language list does not prove the tool models the team's actual compiler, build options, and framework conventions; prove that on representative builds.
Healthcare ↗
Device-software changes may need clinical and manufacturer coordination. Testing must use synthetic health data, and components should be tracked across the device lifecycle.
Evaluate: Keep SBOM retention and change evidence aligned with device-lifecycle review rather than treating a hospital web app and a medical device as the same pipeline.
Public sector ↗
Hosting eligibility, exportable evidence, disconnected builds, and supplier attestations vary by organization. NIST SSDF supplies development-practice vocabulary; a tool purchase does not establish conformance.
Evaluate: Demonstrate air-gap or self-managed analysis, SBOM distribution, and attestation export rather than inferring them from a commercial SaaS page.
What drives the operating cost
- Active committers or contributors, and application or scan-unit counts, including how inactive forks and monorepos are billed.
- SCA knowledgebase and malicious-package feeds, plus DAST hours or site profiles.
- On-premises appliances, professional services, and artificial-intelligence remediation or coding-agent add-ons.
- SBOM retention and customer-facing evidence, plus duplicate tooling across quality SAST, AppSec SAST, and image scanning.
- SKU bundling: GitHub Code Security and GitHub Secret Protection billed separately on Team or Enterprise; GitLab richer application-security user experience documented as Ultimate; Sonar composition analysis as paid Advanced Security.
Questions worth asking
- Does the tool explain a reachable failure rather than only a pattern match?
- Can developers reproduce and verify a fix?
- How are exceptions, generated code, and dependency updates handled?
Common assumptions to check
A web application firewall is an application-security program.
A web application firewall is an adjacent runtime control. It can reduce exploitability of some HTTP classes and buy remediation time when the rule covers the path; it does not fix first-party flaws, inventory transitive open-source software, rotate leaked tokens, or prove build provenance. Verify the code fix separately.
Generating an SBOM, or buying ASPM, replaces SAST, SCA, and DAST engines.
Those engines find different classes of problems. An unsigned SBOM can still be a useful inventory. Signing and attestations can strengthen integrity and origin evidence but are not required for that use. Ingest, retention, component matching, completeness notes, and distribution determine whether the inventory stays useful. ASPM correlates inputs; it does not create coverage that the engines never produced. Reachability can hide unused-but-shipped components that auditors still want listed.
One GitHub Advanced Security purchase covers both code scanning and secret protection, and Black Duck is still a Synopsys product.
GitHub Code Security and GitHub Secret Protection are separate SKUs with different private-repository entitlements. Black Duck Software, Inc. is the current independent brand of the former Synopsys Software Integrity Group after the 2024 rebrand; do not treat Synopsys AppSec as the live product name.
APPLY THE IDEA / EVALUATION PLAN
Make the outcome observable.
Write a test for a cross-user authorization boundary. Confirm it fails when the control is deliberately removed in a local sandbox.
Seed a non-production application
Use a non-production Git organization, a synthetic app with intentionally seeded OWASP-class flaws, a pinned vulnerable open-source library, a vendor-supported safe secret pattern or a configured synthetic rule with no real access, a container base image, and a throwaway registry. Production URLs, real credentials, and arbitrary fake text assumed to be detected stay out of scope.
Measure coverage, precision, secrets, and inventory
Record which lab languages and package managers scan without manual rebuild hacks. Dual-review a sample of static and composition findings on this corpus only. Test push protection or pull-request blocking against an approved nonfunctional secret pattern or a configured synthetic rule and its documented applicability; secret validity checks may reject fake credentials. Check that a CycloneDX or SPDX SBOM emitted at build contains the seeded library and a digest, and document completeness gaps.
Verify provenance, staging DAST, and the web-application-firewall contrast
Require provenance or an attestation in the lab registry and fail a valid signature from an unexpected identity. Scan staging only and confirm at least one seeded runtime issue. Enable a lab web-application-firewall rule for one issue and show the code still contains the flaw. Stop if a test reaches production, leaves agreed scope, or requires real customer data.
Use synthetic data and an authorized test environment. Record scope, product edition, permissions, results, and recovery behavior.
Vendors & products
15 profilesAn editorial selection of relevant offerings, with documented scope and practical evaluation questions. Atlas Fold provides a separate provisional documentation assessment for selected offerings; inclusion in this directory is not a ranking.
Black Duck / Application security testing and software composition analysis
Black Duck Polaris, Coverity, and SCA
The broader portfolio includes static, dynamic, interactive, composition, and protocol testing. Confirm language coverage, deployment and data flows, module entitlements, and the current contracting and support entity for an existing agreement.
Checkmarx / Application security platform
Checkmarx One
Source-upload versus air-gap deployment, Fusion or hybrid engine accuracy on the local stack, and whether ASPM can land analytics without locking to Checkmarx scanners are buyer tests. Documentation describes ASPM as a landing analytics surface rather than a replacement engine.
Veracode / Application risk management
Veracode ARM platform
Binary-only analysis, pipeline-scan latency, and a cloud-only constraint versus regulated on-premises needs are the main boundary tests. Dynamic testing belongs on non-production sites. Package-firewall and Risk Manager modules should be confirmed as entitled rather than assumed from the platform name.
Snyk / Developer-workflow application security
Snyk
Reachability versus raw CVE volume, regional hosting, and trial versus Enterprise governance are the evaluation surface. IDE, CLI, and source-control seating is the intended workflow. DAST remains a running-app test and should stay off production.
GitHub (Microsoft) / Source-control native code and secret security
GitHub Code Security and GitHub Secret Protection
Do not assume one license covers secrets and code. Secret push protection and branch protection are distinct controls. Committer metering and languages outside CodeQL are separate tests. Public-repository entitlements do not automatically apply to private repositories.
GitLab / Source-control and CI application security
GitLab SAST and dependency scanning
Confirm each analyzer and reporting feature against the deployed GitLab version and tier. Self-managed hosting changes operational responsibilities; it does not remove license requirements. Use review apps or staging for the dynamic-testing exercise.
Semgrep / Custom-rule static analysis and supply-chain platform
Semgrep AppSec Platform
Community Edition versus paid rule quality, lockfile layout for supply-chain results, and interfile analysis on monorepos are the main tests. Community Edition is SAST patterns; composition reachability, secrets, and SBOM are platform features and should not be assumed in the free engine.
SonarSource / Quality platform with paid software composition analysis
SonarQube Advanced Security
The Advanced Security add-on requires an eligible Server edition and entitlement. Verify documented cloud-analysis and local-parsing data flows before enabling either mode; local parsing is not an air-gap guarantee. Compare its results with existing SCA coverage.
HCLSoftware / Application security testing
HCL AppScan
Product SKU sprawl is the main teaching hazard: Standard, Enterprise, Source, on Cloud, and 360° are not interchangeable. Correlation of SAST and DAST, and whether self-managed air-gap actually matches the needed engines, must be proven per SKU.
OpenText / Static application security testing
OpenText Fortify SAST
Audit Workbench style review, false-positive handling, and the OpenText versus former Micro Focus contract and support path are operational boundaries. Language-list marketing does not prove the team's compiler and framework are modeled. Self-managed analysis is a reason teams still evaluate Fortify for regulated code.
Mend.io / Software composition analysis and developer remediation
Mend.io
Renovate merge risk, container coverage, and evidence export are part of the product boundary. Reachability can reduce noise and can also hide shipped components. WhiteSource is a historical name; current brand is Mend.io.
Endor Labs / Reachability-first composition analysis
Endor Labs
Call-graph completeness, Bazel and monorepo support, and the difference between a free Model Context Protocol integration and an enterprise policy plane are buyer tests. Reachability can hide unused-but-shipped components that still belong on an SBOM.
Legit Security / Application security posture and SDLC discovery
Legit Security
Discovery coverage of the actual toolchain, and whether ASPM works without ripping out existing scanners, are the evaluation surface. Secrets beyond git and CI/CD posture checks need authorized access to those systems. VibeGuard is vendor-described until tested in the team's own agentic workflow.
Chainguard / Hardened rebuilds and provenance
Chainguard
Check artifact compatibility, update availability, and provenance policy. Hardened base artifacts do not replace static analysis of first-party application code or composition analysis of the dependencies added by that application. Provenance describes origin and build evidence, not freedom from bugs.
JFrog / Artifact-registry security
JFrog Xray, Advanced Security, and Curation
What Artifactory and Xray already cover, Advanced Security add-on entitlements, repository policy latency, and metadata or source handling must be confirmed. Registry policy is not builder isolation, and a signature elsewhere does not replace Xray's artifact analysis.
Learn this before you shop
- NIST SSDF Version 1.1 explainer (shared practice vocabulary, not an SBOM)
- OWASP Top 10 explainer (awareness list literacy)
- OWASP ASVS explainer (verification requirements literacy)
- Learn path: From dependency to decision
- Map Chronos Hub’s trust boundaries
- Dependencies and transitive risk
- Who can write, who can promote
- An SBOM is inventory, not a control
- Lab: Defer with a date, or patch for a reason