> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/trust-and-coverage/coverage.md). # 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. | Marker | Means | | --------------------- | ------------------------------------------------------------------------------------------ | | **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 | Capability | Maturity | What it replaces | Covers | Triggered by | You get | | --------------------------------------------------------------------------------------------------------------------------- | ----------------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | | [Code analysis](/capabilities/code-reviews/code-analysis.md) | 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 | | [Infrastructure as code](/capabilities/code-reviews/code-analysis/supported-languages.md#infrastructure--build-definitions) | 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](/capabilities/remediations.md) for available actions | | [Dependency analysis](/capabilities/code-reviews/dependency-analysis.md) | 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 | | [Container analysis](/capabilities/code-reviews/dependency-analysis.md) | 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 | | [Secrets detection](/capabilities/code-reviews/secrets-detection.md) | 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 | | [Supply chain posture](/capabilities/scpm.md) | 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 | | [Cloud audits](/capabilities/cloud-audits.md) | 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 | | [Context engine](/capabilities/context-engine.md) | 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 | | [Triage](/capabilities/triage.md) | 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 | | [Exploit validation](/capabilities/pentests/exploit-validation.md) | 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 | | [Bug hunts](/capabilities/bug-hunts.md) | 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 | | [Pentests](/capabilities/pentests.md) | 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 | | [Autofix and remediation](/capabilities/remediations.md) | 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 | | [Threat intelligence](/capabilities/threat-intelligence.md) | 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 | | [Campaigns and program management](/capabilities/program-management.md) | 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 | | [Connectors](/connectors/connectors.md) | 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. | | Starts from | Scope | Runs when | Produces | | ---------------------- | ------------------------------- | --------------------------------------------------------------------- | ----------------------------------------- | -------------------------------------------------------------- | | **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](/capabilities/remediations.md) 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. | Not covered | Status | | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **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: * [Code Reviews](/capabilities/code-reviews.md) — [languages](/capabilities/code-reviews/code-analysis/supported-languages.md), [ecosystems](/capabilities/code-reviews/dependency-analysis/supported-ecosystems.md), [secret categories](/capabilities/code-reviews/secrets-detection/supported-secret-categories.md) * [Cloud Audits](/capabilities/cloud-audits.md) · [Supply Chain Posture Management](/capabilities/scpm.md) · [Context Engine](/capabilities/context-engine.md) * [Triage](/capabilities/triage.md) · [Remediations](/capabilities/remediations.md) · [Security Program Management](/capabilities/program-management.md) * [Pentests](/capabilities/pentests.md) — [engagement workflow](/capabilities/pentests/engagement-workflow.md), [exploit validation](/capabilities/pentests/exploit-validation.md), [supported targets](/capabilities/pentests/supported-targets.md) * [Bug Hunts](/capabilities/bug-hunts.md) · [Connectors](/connectors/connectors.md) * [Trust Center](/trust-and-coverage/trust-center.md) — data handling, subprocessors and assurance ## Change log | Date | Change | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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. |