Replacing Checkmarx with Open Source — Designing an AppSec Stack from SAST, SCA, IaC, and Secrets

Checkmarx One is a commercial ASPM (Application Security Posture Management) platform that unifies static analysis (SAST), software composition analysis (SCA), Infrastructure as Code (IaC) security, secrets detection, and dynamic analysis (DAST) into a single product. It is a de facto standard in the enterprise space, but its steep licensing cost, long scan times, and the tuning cost of suppressing false positives are common pain points across many organizations.

This article lays out how to design an open-source replacement for Checkmarx, organized by category (SAST, SCA, IaC, secrets, DAST) and by the management layer that binds them together. The conclusion up front: no single OSS tool replaces Checkmarx one to one. The realistic answer is a loosely coupled multi-engine setup that combines category-specific OSS tools and binds them with an integrated vulnerability-management platform.

The premise: no single OSS replacement exists

Checkmarx One (cloud) and CxSAST (on-premises) bundle nine scan engines (SAST, SCA, DAST, IaC, container, secrets, API security, and more) into one platform and correlate and prioritize results at the ASPM layer. Per Checkmarx, CxSAST natively supports 35+ programming languages and 80+ frameworks. So “replacing Checkmarx” means reproducing these multiple categories with individual OSS tools.

The strength of a commercial platform lies in correlating multiple scan results to assess true attackability. An approach that relies on static analysis alone mass-produces unnecessary warnings against dead code and imposes a heavy triage burden on developers. That is why modern AppSec architecture favors placing high-performance, category-specialized OSS scanners and aggregating and deduplicating them in a central management layer, rather than depending on a single bloated product.

There is an irony worth noting: Checkmarx itself owns and operates two well-known OSS projects. The IaC scanner KICS and the DAST tool OWASP ZAP (maintained as “ZAP by Checkmarx” and still Apache-2.0). So a Checkmarx replacement stack can end up containing Checkmarx-built OSS.

SAST — the Semgrep CE versus Opengrep split

SAST, the core of Checkmarx, is the hardest area to reproduce fully with OSS. The reason is that the cross-file, cross-function data-flow (taint) analysis that commercial tools provide is restricted in many OSS tools.

The constraints of Semgrep Community Edition

Semgrep processes code structurally as an abstract syntax tree (AST) rather than text, and its pattern-matching engine delivers fast scans across 30+ languages. Its popularity comes from a low barrier to writing rules in YAML that look almost like the code itself.

In December 2024, however, the vendor Semgrep, Inc. rebranded the former Semgrep OSS as Semgrep Community Edition. The engine license stayed LGPL-2.1, but advanced features such as cross-file and cross-function data-flow analysis, fingerprint generation, and ignore tracking were removed from the community edition and confined to the commercial version. The rule sets were also relicensed under Semgrep Rules License v1.0, which restricts use to “internal business purposes only.” In practice: the engine is OSS, but the main rule sets are not purely open source.

This constraint bears directly on accuracy. In a benchmark independently conducted by Doyensec (commissioned by Semgrep, using OWASP WebGoat and Juice Shop), on WebGoat the single-file Community Edition detected 48% of vulnerabilities (16 findings), whereas the paid Pro tier with cross-function analysis detected 72% (24 findings), a roughly 50% gap in true-positive rate (Juice Shop showed a similar trend, 44% versus 75%).

The birth of the Opengrep fork

To counter this commercialization and keep the advanced analysis features that were split out of Semgrep CE free and open, the Opengrep project was launched. In January 2025, a consortium of more than ten DevSecOps vendors, including Aikido Security, Endor Labs, Jit, Orca Security, and Kodem, forked the last full-featured CE codebase under LGPL-2.1 before the restrictions landed.

Opengrep restored inter-procedural data-flow tracking (taint analysis) for 12 languages, added fingerprint generation, and even added Visual Basic support that Semgrep lacks. It is fully compatible with existing Semgrep community rules and custom YAML rules, and its JSON and SARIF output are compatible too. It is CLI-only, completely free, and has no commercial tier. For organizations that want commercial-grade analysis depth for free while avoiding vendor lock-in, it is the strongest choice right now.

Complementing with language-specific scanners

A general-purpose SAST alone risks missing vulnerabilities specific to particular frameworks. A useful approach keeps a general engine as the base while adding dedicated linters that deeply understand language-specific semantics.

Bandit: Python only. Quickly detects hardcoded passwords, dangerous built-in functions, and SQL injection patterns (Apache-2.0).
Brakeman: the go-to for Ruby on Rails. Optimized for Rails-specific routing, data flow, and misconfigurations, it suppresses the false positives typical of general-purpose tools. Note that the current version uses its own Brakeman Public Use License, and a fully MIT fork, Railroader, exists separately.
gosec: walks Go’s AST to detect Go-specific issues such as crypto misuse, SQL injection, and hardcoded credentials (Apache-2.0).
SpotBugs + Find Security Bugs: for the JVM (Java, Kotlin, Scala, Groovy). Bytecode analysis detects 128 vulnerability types. Note that Find Security Bugs’ last public release was in 2020, so its maintenance freshness carries risk.

Two more general engines belong on the evaluation list: SonarQube and CodeQL. SonarQube Community Build is excellent as a code-quality and operations foundation, but taint analysis, PR decoration, and branch analysis are commercial-only. CodeQL comes closest to commercial depth in semantic analysis, but it carries a significant license constraint: using it in CI/CD on proprietary code requires the paid GitHub Advanced Security. Free use is limited to open-source code and academic research.

Comparing the SAST tools

Criterion	Semgrep Community Edition	Opengrep	SonarQube Community Build
License	Engine: LGPL-2.1 / Rules: Semgrep Rules License v1.0	Engine and rules both LGPL-2.1 (unrestricted)	LGPL-3.0
Analysis depth	Single-file, intra-function pattern matching only	Inter-procedural data-flow and taint analysis	Basic vulnerabilities and code quality (taint analysis is commercial-only)
Languages	30+ major languages	30+ plus additions like Visual Basic	20+ (C/C++/COBOL etc. commercial-only)
CI/CD fit	Extremely lightweight, no build environment needed	Lightweight, runs all Semgrep rules	Free tier centers on the main branch
Key strength	Adoption track record and community maturity	Advanced analysis without commercial constraints, vendor-consortium backing	Unified management with code quality

SCA — dependency scanning centered on Trivy

SCA, which manages vulnerabilities in dependency libraries and container images, is as important as SAST on first-party code. This is the area where OSS comes closest to commercial tools, and a Trivy-centered setup covers it well.

Trivy, developed by Aqua Security, is a multi-layer scanner that can scan container images, Git repositories, file systems, and Kubernetes clusters from a single binary. In the pre-build phase it parses each language’s lock files (package-lock.json, poetry.lock, go.mod, Cargo.lock, and so on), and in the post-build phase it identifies installed packages inside a container. Its vulnerability database syncs not only NVD but also the GitHub Advisory Database and each Linux distribution’s advisories automatically. For SBOM generation, it natively supports CycloneDX and SPDX.

Whereas Trivy is an all-in-one, Anchore’s Syft (SBOM generation) and Grype (vulnerability scanning) are single-purpose tools in the Unix tradition, easy to slot partially into an existing pipeline. Google and the OpenSSF’s OSV-Scanner uses the OSV database and produces fewer false positives thanks to ecosystem-specific matching.

For continuous monitoring across a portfolio, OWASP Dependency-Track fits well. It ingests SBOMs and re-evaluates them continuously, re-checking impact each time a new CVE is published. Automating fix PRs is left to Dependabot or Renovate.

License scanning warrants caution, however. Trivy’s --scanners license classifies dependency licenses by SPDX identifier, but in certain versions the CycloneDX output emits both a “license ID/name” and an “SPDX license expression” in the same array simultaneously, causing parse errors in downstream validators (Issue #9300). Do not over-trust automated validation; tune the policy appropriately via trivy.yaml.

IaC and secrets

IaC: Checkov, KICS, Trivy config

For detecting IaC misconfigurations, Checkov is the strongest. Developed by Prisma Cloud (Palo Alto), it supports a wide range of formats including Terraform, CloudFormation, Kubernetes, Helm, ARM, and Bicep. On top of 1,000+ built-in policies, its graph-based cross-resource analysis, which other OSS tools lack, is a distinct strength.

Checkmarx’s own KICS is also strong. Fully open-sourced under Apache-2.0, it covers 22+ platforms including Terraform, Kubernetes, Ansible, Docker, CloudFormation, Bicep, Pulumi, and GitHub Workflows. Its 2,400+ queries are written in Open Policy Agent’s Rego, so you can add your own rules as code. It returns exit codes by severity, making pipeline gating easy. Trivy’s config scan inherits tfsec’s check library (see below) and is handy when you want one tool to cover IaC as well.

Be aware that this area has seen several sunsets. tfsec has had all its checks folded into Trivy and gets no new features, and Terrascan was archived (made read-only) by Tenable on November 20, 2025. Existing pipelines still run, but CVE updates stop, so neither is recommended for new adoption. If you want to reach into Kubernetes runtime, Kubescape (CNCF Incubating) is an option.

Secrets: Gitleaks, TruffleHog

For secrets detection, Gitleaks is one of the most trusted OSS tools. It detects with regular expressions and entropy, can scan the entire Git commit history (gitleaks detect), and offers a protect mode (gitleaks protect) that evaluates only the diff before a commit. To keep a flood of false positives buried in old code from paralyzing a team, you can commit the first scan’s results as a baseline and thereafter detect only newly introduced leaks. The core CLI is MIT, but note that the gitleaks-action GitHub Action requires a free license key for organizational use.

TruffleHog takes a verification-first approach, actually checking via API whether a detected credential is still live. It has 800+ detectors and suits history scans and incident response (v3 and later are AGPL-3.0, so watch for copyleft propagation when integrating). For retrofitting onto legacy code, detect-secrets (Yelp, Apache-2.0), with its baseline feature, fits well. The standard play is a pairing: Gitleaks for pre-commit and fast CI blocking, TruffleHog for periodic history scanning and verification.

Gitleaks’ lead developer, incidentally, is moving from the now feature-complete Gitleaks (henceforth mostly security patches) toward a next-generation tool. Replacing the old TOML regex-based allowlist, it adopts a CEL (Common Expression Language)-style expression language, which lets you flexibly express exclusions for path patterns and dummy strings, curbing config bloat while reducing false positives further.

ASPM — binding it all with DefectDojo

Merely running individual OSS point tools in parallel in a pipeline means checking and triaging each scanner’s report separately, and the operational burden ends up exceeding that of a commercial tool. To prevent this “alert fragmentation” and reproduce Checkmarx One’s central management portal with OSS, put the OWASP flagship project OWASP DefectDojo at the core.

DefectDojo is built on Python (Django) and runs as an extensible, production-grade system with Celery workers for heavy asynchronous processing and a message broker (Valkey or Redis) to relay jobs. It can ingest results from 200+ tools and expresses security governance through a layered data model of Product Type, Product, Engagement, Test, and Finding. The license is BSD-3-Clause open core.

DefectDojo’s greatest value is smart deduplication, which automatically merges alerts reported redundantly across different tools or multiple scans. On import, it compares CWE classification, file path, line number, endpoint, and the scanner’s own ID or a custom hash, and folds vulnerabilities it deems identical into child nodes of an existing Finding. This can automatically compress 500 raw alerts down to roughly 150 unique issues that actually need attention.

For the remediation flow, it supports bidirectional sync with Jira. “Push to Jira” from a triage result creates a ticket automatically, and closing that ticket on the Jira side rewrites the DefectDojo Finding to Remediated or Risk Accepted via webhook.

The diagram below shows how the OSS point tools and DefectDojo connect to reproduce Checkmarx’s unified management.

graph TD
    A[Developer changes code] --> B(Pre-commit Hook: Gitleaks)
    B -->|No secret found| C[Push to Git repository]
    C --> D[CI/CD pipeline starts]
    subgraph Scanners [Parallel scanners]
        D --> E[SAST: Opengrep]
        D --> F[SCA: Trivy]
        D --> G[IaC: Checkov / KICS]
    end
    E -->|SARIF output| H[DefectDojo REST API]
    F -->|JSON output| H
    G -->|JSON output| H
    subgraph Dojo [DefectDojo ASPM]
        H --> I[Import / auto-deduplication]
        I --> J[CVSS / EPSS severity and SLA]
    end
    J -->|Bidirectional| K[Auto-create Jira ticket]
    K -->|Webhook sync| J
    J -->|Notify| L[Slack alert]

To add DAST, wire the Checkmarx-owned OWASP ZAP into CI. ZAP is the strongest free DAST, offering proxy, spider, and active/passive scanning with support for REST, GraphQL, and SOAP. Pairing it with Nuclei, which detects known CVEs quickly with YAML-based templates, covers a good share of API security too.

Developments to track in 2025–2026

This space moves fast, so refresh your assumptions when designing.

Semgrep OSS was renamed to Community Edition (December 2024). Cross-function analysis and other features moved to the paid tier, and rules were relicensed restrictively.
The Opengrep fork appeared (January 2025), restoring cross-function taint analysis and shipping releases roughly weekly.
tfsec was folded into Trivy, and Terrascan was archived on November 20, 2025. The IaC landscape has tilted toward Checkov and Trivy.
SonarCloud became SonarQube Cloud, and Community Edition became Community Build.

The heaviest development is a supply-chain attack. In March 2026, a threat actor exploited leaked credentials to inject credential-stealing malware into Trivy binaries, trivy-action, setup-trivy, and even Checkmarx’s KICS GitHub Action (CVE-2026-33634, CVSS 9.4, Critical). Only some tags protected by GitHub’s immutable releases were untouched. The lesson is clear: pin GitHub Actions to full commit SHAs, not mutable tags such as @v1. You need to bake into your design the reality that security tools themselves are now attack targets.

The limits and trade-offs of going open source

This multi-engine setup can cut licensing costs dramatically, but before committing to a migration, weigh these limits too.

Legacy-language coverage: one of Checkmarx’s strengths is sweeping coverage that includes mainframe-era languages such as COBOL, RPG, PL/SQL, VB6, and ABAP. OSS tools like Opengrep support these poorly, and in environments that scan legacy code daily (financial or government systems), replacing Checkmarx 100% with OSS alone is technically difficult. A hybrid setup that keeps a commercial SAST for part of the estate becomes the realistic path.
Trade-off in labor cost: a commercial vendor guarantees engine maintenance, vulnerability-feed updates, false-positive tuning, and SLA support. Switching all of this to OSS means shifting the license fee to “the labor cost of an in-house DevSecOps team that maintains triage rules and operates DefectDojo.”
License pitfalls: CodeQL requires paid GitHub Advanced Security for CI/CD on proprietary code, Semgrep’s rules use a restrictive license, Brakeman’s current version uses its own license, TruffleHog is AGPL-3.0 copyleft, and gitleaks-action needs a key for organizational use. Conditions differ per tool, so scrutinize them if you plan commercial distribution or SaaS embedding.
Accuracy and false positives: the single-file Semgrep CE and the CPE-matching OWASP Dependency-Check tend to produce more false positives than commercial tools with reachability analysis. Deduplication and triage operations in DefectDojo become a prerequisite.

Summary

There is no complete one-to-one OSS replacement for Checkmarx, because Checkmarx is not just a SAST engine but a platform that bundles language coverage, query editing, IDE/CI integration, cloud/on-prem deployment, and multi-layer operations.

The realistic answer is a setup built around Opengrep (or Semgrep CE) + Trivy + Checkov/KICS + Gitleaks + OWASP DefectDojo, adding language-specific tools and OWASP ZAP as needed. It is safest to roll out in phases. First put a lightweight stack into CI/CD to establish pre-commit secrets detection and per-PR scanning; once false positives start straining operations, centralize deduplication and triage with DefectDojo; and when SAST taint-analysis accuracy falls short, consider migrating to Opengrep or partially adopting a paid tool.

For organizations centered on modern languages (Java, Python, JavaScript, Go, Rust, and the like) that build their own CI/CD, this setup is a compelling strategy for cutting costs and escaping vendor lock-in. In environments with a high share of legacy languages, or organizations with limited in-house resources to devote to operations, keeping a commercial tool or running a hybrid can still come out ahead on total cost. Starting from your own language mix and operating structure, and beginning with the functional decomposition, is the right order.

That’s a field note, from someone who works with application security day to day, on how to redesign a Checkmarx replacement as an OSS stack spanning SAST, SCA, IaC, and secrets.