Product Coverage
One page: what Nullify does, what each capability replaces, how it is triggered, what you get out of it, and where the boundaries are.
Owner
Nullify Product — changes to a capability's coverage or maturity marker require product review before merge. Repository documentation ownership is defined in .github/CODEOWNERS
Review cadence
Every release train, and on any change under public-docs/capabilities/
Last reviewed
2026-09-07
Maturity taxonomy
These markers describe the documented capability category. They do not certify availability in every deployed version; confirm tenant configuration and rollout requirements before relying on a capability.
GA
Documented for customer use; availability depends on deployment version and configuration.
Beta
Documented with rollout or coverage limitations; confirm tenant availability.
Operator-assisted
Documented with operator involvement.
Roadmap
Documented intent, not shipped. Nothing on this page carries this marker today.
Coverage at a glance
GA
Standalone SAST (Semgrep, Snyk Code, Checkmarx, Fortify) plus the triage headcount around it
16 application languages — C, C++, C#, Go, Java, JavaScript, TypeScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Solidity, Apex, Swift
Push, pull request, and a scheduled default-branch scan
Triaged findings with a priority, a reachability verdict, and an autofix pull request where one is safe
GA
Checkov, tfsec, Snyk IaC, KICS
Terraform (AWS, Azure, GCP) and Kubernetes — 376 rule files in one ruleset
Repository source checks
Source-file misconfigurations; see Remediations for available actions
GA
Dependabot alerts, Snyk Open Source, Renovate security updates
19 ecosystems across npm/pnpm/Yarn/Bun, PyPI/Poetry/Pipenv/uv/Conda, Go, Maven/Gradle, NuGet, Cargo, RubyGems, Composer, Swift PM, Dart, Elixir
Push, pull request, scheduled scan, and new-advisory re-evaluation
Reachability-filtered CVEs and upgrade pull requests, verified against the ecosystem's own toolchain where the ecosystem supports it
GA
Trivy, Grype, Snyk Container
OS and language packages in built images and Dockerfiles
The same repository and registry scan
Image findings with the fixed version and a base-image recommendation
GA
GitGuardian, GitHub secret scanning, TruffleHog
Credential and confidential-data categories, with live verification against the issuing provider
Push, pull request, and full-history scan
Findings that say whether the credential is live, with the secret stored redacted
Beta
Vendor SCA add-ons, ad-hoc CI linting, manual lockfile review
Manifests, lock files and CI/CD definitions across npm, Python, Go, Maven/Gradle, NuGet, Cargo, Ruby, Composer, Docker, GitHub Actions, GitLab CI, Azure Pipelines, Dependabot, Renovate
Default-branch scan and diff-scoped pull-request scan
Typosquat, unpinned-dependency, install-script, licence and pipeline-hardening findings, with pull requests where the fix is a code change
Beta
Wiz, Prisma Cloud, AWS Security Hub, Scout Suite
AWS, Azure, GCP and Kubernetes posture — 900+ rules
Scheduled scan against the cross-account role you create
Misconfiguration findings with the affected account, region and resource, linked back to the IaC that created it where a mapping exists
GA
The internal wiki nobody updates, plus the architecture interview at the start of every assessment
Repository, organisation and cloud context — ownership, asset graph, attack paths
Onboarding, then continuously as repositories and cloud change
The evidence every other capability prioritises with: what is internet-facing, who owns it, what it talks to
GA
The security engineer who reads every scanner alert and decides what is real
Every finding type the platform produces
Automatic for supported finding workflows
A priority, a false-positive verdict, and the reasoning and evidence behind both
GA
Manual "is this actually exploitable?" verification of individual findings
Code and dependency findings against your registered web targets
A policy you own, matched to a finding — not a schedule
One finding, one verdict, with reproduction evidence
GA
Continuous external attack-surface monitoring and bug-bounty triage
Your external surface, within a scope you define
Scheduled and on-demand
Exposure findings on live hosts, with the scope gate enforced in the request path
Operator-assisted
A scheduled third-party penetration test
REST and GraphQL APIs on applications you register
On demand, per application; self-serve initiation is per-tenant flagged
Auth, authorisation and business-logic findings with reproduction evidence, and a report
GA
The remediation backlog and the engineer assigned to work it
Code, dependency, container, supply-chain and IaC findings
Automatically on eligible findings, on request, or as part of a campaign
A draft pull request, reviewed and verified before it is opened
GA
Vendor threat-intelligence feeds plus the manual "are we affected?" scramble after each disclosure
Newly disclosed vulnerabilities and malicious-package compromises from public advisory sources and Nullify research
New published threats (automatic, opt-in) or a manual request
A per-threat assessment of affected repositories and packages, with remediation guidance
GA
The vulnerability-management spreadsheet, the SLA tracker and the weekly chase
Every remediable finding type, with per-type actions (pull request, ticket, runbook)
A campaign you define, or a scheduled programme plan
Scoped work with owners, tickets, SLA tracking and a posture report
GA
The integration glue you would otherwise build
GitHub, GitLab, Bitbucket, Azure DevOps, Slack, Teams, Jira, Linear, Compass, AWS, GCP, Kubernetes, Buildkite, Jenkins, CircleCI
Set up once during onboarding
Findings, tickets and notifications where your team already works
Pentest, exploit validation, AI code review, bug hunt
The four are routinely conflated. They differ in what they start from and what they produce.
Pentest
An application you register
Broad: map the app and hunt for anything exploitable
On demand, per engagement
Auth, authorisation and business-logic findings, plus a report
Exploit validation
One finding that already exists
Narrow: that finding, that endpoint
A policy match on a newly triaged finding
A verdict on that one finding, with reproduction evidence
AI code review
A pull request
The diff, in the context of the repository
Every pull request
Review comments and suggested changes before merge
Bug hunt
Your external surface
Whatever is in the scope you define, whether or not you knew about it
Scheduled and on demand
Exposure findings on live hosts
Pentest and exploit validation share the same exploitation engine; the difference is breadth, not fidelity.
One IaC detection path
Terraform and Kubernetes misconfigurations are found by the same repository scan as the rest of code analysis, using the rules under sast/tools/opengrep/rules/terraform/. There is no second IaC scanner and no separate stage.
tfsec exists in the Nullify CLI as a local convenience runner. It is not part of the server-side pipeline and does not produce platform findings.
Repository IaC checks report misconfigurations in source files. Cloud posture checks evaluate collected cloud configuration. Their remediation capabilities are described on the Remediations page.
What we do not do
Named so an evaluation does not have to discover them by absence. These are documentation boundaries; they do not establish delivery commitments.
Cloud drift detection — proving the live resource no longer matches the committed Terraform
Out of scope for now. A cloud posture finding or a source-code misconfiguration does not establish that a specific resource drifted from committed Terraform.
Vendor and third-party risk assessment
Partner. Nullify generates the SBOM; vendor questionnaires, tiering and assessment workflow belong in a dedicated vendor-risk tool that consumes it.
Developer security training and enablement
Out of scope. Nullify's developer touchpoint is the pull request — the review comment and the fix — not a curriculum.
Threat modelling and design review
Not described as supported here. Nullify already collects the threat models you upload during onboarding and stores them as tagged context documents, and already models what a threat model reasons over (asset graph, attack paths), but does not produce or maintain one.
Secret revocation and rotation
Not described as supported here. Nullify detects a leaked credential and verifies whether it is still live; it does not call the provider to revoke it or orchestrate rotation.
Policy as code
Not described as supported here. Findings are gated by thresholds and per-tenant configuration, not by a policy object with its own exception chain.
Business asset criticality
Not described as supported here. Ownership and scope-selection criticality exist; a crown-jewel tier and data-classification level that severity reads from do not.
Runtime/agent-based workload protection
Out of scope. Nullify analyses code, dependencies, configuration and live application behaviour over the network; it does not install a runtime agent on your hosts.
Where to go deeper
Each capability has a maintained page with its own supported-coverage detail:
Trust Center — data handling, subprocessors and assurance
Change log
2026-09-07
First publication. Coverage table, maturity taxonomy, the four-way pentest / exploit validation / AI code review / bug hunt distinction, the single IaC detection path, and the explicit not-covered list.
Last updated