Open Source AppSec Tools Landscape Guide: SAST, SCA, Secrets and DAST Without Licences

Most teams can build a credible application security testing programme from open source tools, but "free" tools still carry licence conditions, maintenance risk and real engineering cost, and picking the wrong mix leaves gaps nobody notices. This guide maps the main open source options for static analysis (SAST), software composition analysis (SCA) and SBOMs, secret scanning, infrastructure as code (IaC) scanning, dynamic testing (DAST) and findings management. For each category it explains what the tools do, where their licences restrict use, how to deploy them safely in pipelines, and how to measure whether the combination is working. It is written for application security engineers, DevSecOps and platform teams, and security leads in organisations that want strong coverage without per-seat licences. It is vendor-neutral: tools are named to explain the landscape, not recommended.

Key takeaways

• Cover five layers, not one tool. A working open source stack combines SAST, SCA with SBOMs, secret scanning, IaC scanning and DAST, then sends all findings to one place.
• "Open source" is not one licence. Bandit, OSV-Scanner, Trivy and ZAP are Apache 2.0, Gitleaks is MIT, Semgrep Community Edition is LGPL 2.1, TruffleHog is AGPL 3.0, and CodeQL may only be used on OSI-licensed open source code unless you hold a GitHub Advanced Security licence.
• Maintenance status matters as much as features. Gitleaks now describes itself as feature complete with security patches only, and Dependency-Track 4.x reaches end of life in December 2026.
• Scanners are privileged software. They run inside pipelines that hold deployment secrets, so pin them by digest or commit SHA like any other dependency.
• Integration is the hidden cost. Rule tuning, baselines, deduplication and developer workflow take more effort than installing the tools.

What the tool does

Each category answers a different question about the software you ship. The table summarises the main open source options and the licence each project states. Check the licence file of the exact version you adopt, since projects do change terms.

Licences that change the decision

• CodeQL: the CodeQL Terms allow analysis of open source codebases (released under an OSI-approved licence) and academic research, but prohibit use with code that is not open source, such as a private repository, unless the organisation holds a GitHub Advanced Security licence. Many teams discover this only after building pipelines on it.
• Semgrep: the engine is LGPL 2.1, but the rules Semgrep maintains are under the Semgrep Rules License v1.0, which permits internal business use and restricts vendors from using them in competing products. See the Semgrep Guide.
• TruffleHog: AGPL 3.0 since v3.0. Running it internally is common; embedding or offering it as a network service to others triggers copyleft obligations, so check with your legal team first.
• Permissive tools: Apache 2.0, MIT and BSD 3-Clause projects can be used internally and commercially with attribution, which is why they dominate pipeline tooling.

Defender use cases

• Pre-commit secret blocking: Gitleaks ships a pre-commit hook and a baseline option (--baseline-path) so new leaks are blocked without re-reporting old ones. TruffleHog adds verification, marking results as verified when a credential is confirmed live through an API call (--results=verified), and claims to classify over 800 secret types. See the Git Secret Scanning Guide.
• Pull request SAST: Semgrep CE or Bandit run in seconds on changed files and report in SARIF, so findings appear inline in code review.
• Dependency risk in every build: OSV-Scanner reads lockfiles across 11 or more ecosystems and container images, queries OSV.dev, offers an offline database mode and, in V2, optional call analysis to reduce findings for unused vulnerable functions. OWASP Dependency-Check identifies components through CPE evidence against NVD data and integrates with Maven, Gradle, Ant, Jenkins, GitHub Actions and Azure DevOps.
• Portfolio-wide SBOM monitoring: Dependency-Track ingests CycloneDX SBOMs and VEX, monitors every project version continuously, applies security, licence and operational policies, and pulls intelligence from NVD, GitHub Advisories, OSV, Sonatype OSS Index, Snyk, Trivy and VulnDB with EPSS for prioritisation. When a new critical vulnerability is published, it answers "where do we use this?" in minutes. See the SBOM Guide.
• IaC and pipeline policy: Checkov covers Terraform, OpenTofu, CloudFormation, Kubernetes, Helm, Kustomize, Dockerfile, Bicep, ARM and Ansible, plus CI definitions such as GitHub Actions and GitLab CI, with over 1,000 built-in policies. See the Trivy Guide for the overlapping Trivy scanners.
• Running application tests: ZAP's baseline scan gates every deployment and its full or API scans test staging nightly. See the OWASP ZAP Guide.
• One queue for developers: DefectDojo deduplicates and tracks findings from all of the above, and Dependency-Track integrates with it natively.

Deployment and safe use

Rollout in phases

1. Secrets first. Leaked credentials are the fastest route to compromise, so start with a secret scan of full git history, revoke and rotate what is found, then add pre-commit and pipeline scanning with a baseline.
2. SCA and SBOM next. Generate an SBOM for every build artefact, scan it in the pipeline, and upload it to a portfolio platform. Fail builds only on critical, fixable findings at first.
3. SAST on pull requests. Start with a small, high-confidence rule set in report-only mode, measure false positives with developers for two or three sprints, then gate on the rules developers trust.
4. IaC scanning. Add it where infrastructure code lives, suppressing checks that conflict with documented architecture decisions, with a reason in the suppression.
5. DAST. Add a passive baseline scan to deployments, then active scans against test environments only, with written authorisation.
6. Consolidate. Feed all outputs (SARIF, JSON, CycloneDX) into one findings platform and report from there.
7. Rollback. Every gate needs a documented bypass: a time-limited exception in the rules or baseline file, approved by the security owner, never removal of the scan step.

Safe operation

• Pin scanners: reference container images by digest and actions by full commit SHA. In the Trivy supply chain attack, an attacker with a stolen token published a malicious release and force-pushed action tags so that pipelines running the scanner leaked their CI secrets. The same campaign then reached the Checkmarx KICS supply chain attack.
• Least privilege for scan jobs: run scanners in jobs with read-only repository tokens and no deployment credentials, and avoid running untrusted fork code in privileged workflow contexts.
• Data handling: secret scan reports contain the secrets themselves; store them as restricted artefacts with short retention and redact them before ticketing. Secret verification and SCA lookups send data to external APIs, so check what leaves your network and use offline databases (OSV-Scanner offline mode, mirrored vulnerability databases) where policy requires.
• Untrusted projects: OSV-Scanner warns that its guided remediation can be risky on untrusted projects because package managers may run scripts; the same applies to any tool that resolves dependencies.
• Maintenance watch: track project health. Gitleaks has announced that future releases are security patches only, and Dependency-Track 4.x ends support in December 2026 with 5.x as the main line. Plan migrations before support stops.

Where identity fits

Secret scanning is where application security and non-human identity meet. Every API key, token and service account password a scanner finds is a machine identity that needs an owner, rotation and, ideally, replacement with short-lived credentials. The scanners also hold identities of their own: CI tokens, registry credentials and the test accounts used for authenticated DAST. Inventory these alongside other service accounts. See the Secrets Management Guide and the OWASP NHI Top 10 NHI2 Secret Leakage Guide.

Detection and hardening value

Metrics that show it is working

• Coverage by layer: share of repositories with each of the five scan types enabled and gating.
• Secrets: new verified secrets per month and median time from detection to revocation.
• Dependencies: critical and high fixable vulnerabilities in production SBOMs, and the percentage fixed within the time frames your ASVS V15.1.1 documentation sets.
• Signal quality: false positive rate of blocking rules, measured from developer dismissals.
• Tool health: scanners running a supported, pinned version, and days since vulnerability databases last updated.

Common failure patterns

• Building on CodeQL for private code without the licence: the terms restrict non-open-source use, and the fix is either a licence or a migration.
• Many scanners, no owner: five tools each posting to a different place means nobody triages anything. Pick one findings destination first.
• Scanning without rotating: a secret found in history is still live until it is revoked; deleting the commit does not help. The Codecov breach shows how far one exposed key can travel.
• Floating versions of security tools: unpinned images and action tags turn the scanner into the attack path.
• Gating on everything at once: blocking on every medium finding in week one teaches developers to bypass the pipeline.
• Ignoring end of life: unmaintained scanners keep running and quietly stop detecting new issues.

Alternatives

Choose open source when you have engineers to integrate and tune tools, want control over data and rules, and can host a findings platform. Choose commercial platforms when you need cross-file or cross-service analysis beyond community engines, central policy across hundreds of repositories, reachability analysis at scale, or vendor support with service levels. Many organisations run a hybrid: open source secret and IaC scanning everywhere, with commercial SAST or ASPM for crown-jewel applications.

See the Application Security Posture Management (ASPM) Guide, the Application Security Testing Buyer's Guide and the Open Source Cloud Security Tools Landscape Guide.

Practitioner checklist

• Map which of SAST, SCA, secrets, IaC and DAST each application already has.
• Check the licence of every tool and rule set against how you will use it, including CodeQL on private code.
• Scan full git history for secrets and revoke anything found before adding gates.
• Generate an SBOM for every build and send it to one portfolio platform.
• Start every gate in report-only mode, then block only on rules developers trust.
• Pin all scanner images and actions by digest or commit SHA and run them with least privilege.
• Send all findings to one place and assign owners.
• Review project maintenance status yearly and plan migrations before end of life.

Standards and references

• NIST: SP 800-218 Secure Software Development Framework
• OWASP: Application Security Verification Standard 5.0
• OWASP: Dependency-Check
• OWASP: Dependency-Track Documentation
• GitHub: CodeQL Terms and Conditions
• Google: OSV-Scanner
• Gitleaks: Gitleaks
• Truffle Security: TruffleHog

Related NHI Mgmt Group resources: Application Security Guide · DevSecOps Guide · Software Supply Chain Security Guide · Semgrep Guide · Open Source Penetration Testing Tools Landscape Guide