> 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/trust-center.md). # Trust Center Everything a security reviewer needs to evaluate Nullify before a call: where your data goes, who else touches it, how long it is kept, and what we do and do not claim. | | | | ------------------ | ----------------------------------------------------------- | | **Owner** | Nullify Security — | | **Review cadence** | Quarterly, and on any change to the controls described here | | **Last reviewed** | 2026-09-07 | This page describes repository-defined controls and published policies. Deployment configuration and current assurance evidence must be confirmed for your review. See [Assurance status](#assurance-status) for what is and is not independently audited. ## Architecture and tenant isolation Customer processing workloads run in customer deployment stacks. Shared infrastructure hosts the dashboard, sign-in and request router, and identity and connector control-plane services. Those shared services must authenticate the caller and resolve the owning tenant before forwarding workspace requests. * Each customer gets its own deployment stack — its own AWS resources, its own DNS name, its own configuration — provisioned from a Terraform workspace keyed by a deployment id. * Each deployment holds its own database credentials and its own logical database, issued per tenant rather than shared across customers. * For findings, the shared findings query builder puts the tenant predicate on the base table of every query it constructs, and a finding fetched by id is re-checked against the caller's tenant before it is returned. ## Where your source code lives, and for how long * Scan code using the shared working-directory helper registers cleanup of its local directory. This describes that helper, not a retention guarantee for every repository copy or cache. * The cited code-scan infrastructure defines Fargate container tasks. * Deployments that enable the repository clone cache keep it on an encrypted EFS file system with a customer-managed KMS key, reachable only through a single access point from the deployment's own private subnets. * The storage policy specifies Postgres for structured customer data and tenant-scoped database references for opaque object-storage blobs. Existing migrations and dual-write paths must be assessed separately. ### Retention Opaque blob retention uses bucket lifecycle rules. The table shows configured current-version expiry. In a versioned bucket, object bytes remain until the applicable noncurrent-version rule also removes them. | Data | Retention | Where it is configured | | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------- | | Raw code-scan output (findings payloads, scan messages, triage context) | 1 day | `sast/iac/s3.tf` | | Raw dependency-scan output | 1 day | `sca/iac/s3.tf` | | Raw secrets-scan output and triage context | 1 day | `secrets/iac/s3.tf` | | Pentest engagement history | 180 days | `dast/iac/s3.tf` | | Cloud posture triage manifests, results, triaged-finding blobs and finding exports | 180 days by default; configurable per deployment | `cspm/iac/s3.tf` | | Supply-chain raw scan data / triaged-finding blobs / fix cache | 1 day / 90 days / 365 days | `scpm/iac/s3.tf` | | Repository and organisation context artefacts | 180 days | `context/iac/s3.tf` | | Security programme artefacts (plans, campaign state) | 180 days | `manager/iac/s3.tf` | | Superseded object versions | Prefix-specific; reclaimed after the applicable noncurrent-version interval | Each service's bucket lifecycle configuration | Findings themselves — the triaged, deduplicated records you work from in the product — follow the retention and deletion processes described in the Data Handling Policy. ### Encryption * The cited code-scan bucket configuration enables KMS encryption, all four S3 public-access blocks, a TLS policy, and versioning. Consult each service's bucket configuration for its settings. * The repository cache file system is encrypted with its own customer-managed KMS key. ## Business continuity and disaster recovery Recovery is a property of how the platform is built, not a manual procedure someone follows under pressure. Four things carry it. **Customer production database instances have AWS Backup plans.** The primary production instances are configured for continuous, daily, weekly and monthly backups, writing to a KMS-encrypted vault whose access policy denies `backup:DeleteRecoveryPoint`. This describes the configured vault policy, not a guarantee that administrators cannot change that policy. | Plan | Retention | | -------------------------- | ------------------------------ | | Continuous (point-in-time) | 35 days | | Daily | 7 days | | Weekly | 98 days, cold storage after 8 | | Monthly | 365 days, cold storage after 8 | **Primary production databases are configured for Multi-AZ.** They are provisioned with a standby in a second availability zone and deletion protection on, and the module configuration requires a final snapshot on deletion. **Object storage is versioned and encrypted.** The recovery window after an overwrite depends on the object's prefix and its configured noncurrent-version expiry; see [Encryption](#encryption) and [Retention](#retention). **Deployment references use commit SHAs.** The rollout design describes SHA-based deployment and rollback constraints. It is a design reference, not evidence that every live deployment has the same SHA or that a rollback has been tested for your deployment. **Deployment infrastructure is defined in Terraform.** The cited production stack configuration records the resources it manages; it does not establish that every live resource is managed there. For recovery time and recovery point objectives, the DR test schedule, and any available test results, see [Requesting evidence](/trust-and-coverage/trust-center/evidence-requests.md). This page does not state a figure it cannot evidence from the platform itself. ## Authentication and access * **Customers** authenticate to the web application and API through the Nullify auth service. A tenant's identity provider is normally the git provider it onboarded with, and enterprise SSO is supported as an alternative. [Entra SSO](/configuration/account-and-teams/entra-sso-and-scim.md) uses OIDC, with workspace membership, roles and lifecycle governed separately. Entra-only sign-in and [network restrictions](/configuration/account-and-teams/entra-sso-and-scim.md#network-restrictions) require the corresponding enforcement rollout and verified tenant configuration. * **The CLI** uses a browser callback flow and a session issued by the same auth service; it does not ask for a long-lived password. * **Service-to-service** access requirements are declared through the shared route registration configuration. Authentication and permission requirements must be evaluated for the endpoint in use; this page does not establish a universal permitted-callers guarantee for every service route. * **Cloud access** is a cross-account role you create in your own account, trusting a Nullify principal under an external id, and scoped by the template to discovery. Nullify assumes it per scan and holds no long-lived customer cloud keys. * **Outbound requests and repository clones** use HTTP tooling and the connected git provider's clone adapter. Transport and clone safeguards must be evaluated for the specific tool and provider; this page does not establish coverage of every outbound request path. ## Subprocessors | Subprocessor | What it processes | Evidence in the product | | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | **Amazon Web Services** | Platform hosting, storage, databases and queues configured in AWS. Review the deployment regions for residency requirements. | The cited stack and platform configuration define AWS infrastructure | | **Anthropic** (direct API or via **AWS Bedrock**) | Prompts sent to the triage, review and remediation agents. Which of the two backends a deployment uses is configuration. | | | **PostHog** | Feature-flag evaluation keyed on the tenant slug. | | | **Slack / Microsoft Teams** | Notifications you opt into, containing finding metadata. | | | **Jira / Linear / GitHub Issues** | Tickets you opt into, containing finding metadata. | | | **Your git provider** (GitHub, GitLab, Bitbucket, Azure DevOps) | Clone, pull-request and check-run traffic. | | Connectors other than AWS and the LLM backend are opt-in: a deployment with no Slack connection sends nothing to Slack. ## AI and model data use * Customer code and findings are sent to the model backend as prompt content for the duration of a request. * Nullify does not sell customer data and does not use one customer's data to train models for another. ## Secrets and credential handling This covers both directions: the credentials you give Nullify, and the secrets Nullify finds in your code. * **Credentials you give Nullify.** Cloud access is a role you hold in your own account rather than a stored key (see [Authentication and access](#authentication-and-access)). The cited secret-storage implementation provides encryption, and the admin integration configuration separates the package-registry encryption key. Permissions must be checked for the consumer in use. * **Secrets Nullify finds.** The credential-preview model exposes a redacted secret field. That field does not establish the contents or retention of every scanner artifact. * Credential values in captured request bodies and in credential-login traces are redacted before those records are written. ## Pentesting and active testing Nullify's pentest and bug-hunt capabilities send real traffic at real targets, so they carry stricter controls than the read-only scanners. * A target must be registered and validated for the tenant before it can be tested; validation is recorded to an append-only history with the tenant that authorised it. * Requests sent through the cited engagement proxy pass its scope predicate. A host the scope does not permit is answered `403` by the proxy and never forwarded — the scope is a gate in that proxy request path. * An engagement can be stopped at any time through the API, which cancels the running workflow. * Traffic captured during an engagement is body-redacted before it is stored. See [Preparing for an Engagement](/capabilities/pentests/preparing-for-an-engagement.md) for the authorisation Nullify asks for before a first engagement. ## Compliance framework mappings Findings are mapped to the frameworks below, so a finding can be cited in a control-level report. These are **mappings Nullify produces**, not certifications Nullify holds. * CVSS 3.1 (`cvss-3.1`) * CVSS 4.0 (`cvss-4.0`) * OWASP Top 10 2021 (`owasp-top10-2021`) * OWASP ASVS 5.0 (`owasp-asvs-5.0`) * PCI DSS 4.0.1 (`pci-dss-4.0.1`) * NIST CSF 2.0 (`nist-csf-2.0`) * Australian Government ISM (`au-ism`) Cloud posture findings additionally carry the control mappings declared on each cloud rule. ## Data subject rights A tenant administrator can request a scoped user-data export or erasure through the cited endpoints. Review the operation report and the Data Handling Policy for scope and retention qualifications. See the [Data Handling Policy](/more-info/data-handling-policy.md). ## Vulnerability disclosure Report a vulnerability in the Nullify platform to . The intake process, our commitments, and the safe-harbour terms are on the [Security](/more-info/security.md) page. ## Assurance status **No third-party audit report is published from this documentation site.** This page deliberately makes no SOC 2, ISO 27001 or penetration-test-report claim, because none is evidenced here. For current audit status, available policy documents, questionnaires, or business continuity information, contact Nullify Security as described in [Requesting evidence](/trust-and-coverage/trust-center/evidence-requests.md). Availability and release requirements are confirmed per request. ## Vendor-review index Use this table to answer a security questionnaire by citing a canonical section rather than re-deriving the answer. | Questionnaire topic | Answer lives in | | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Multi-tenancy and data segregation | [Architecture and tenant isolation](#architecture-and-tenant-isolation) | | Where customer data is stored, and residency | [Where your source code lives, and for how long](#where-your-source-code-lives-and-for-how-long), [Subprocessors](#subprocessors) | | Retention and deletion schedules | [Retention](#retention) | | Encryption at rest and in transit | [Encryption](#encryption) | | Authentication, SSO, least privilege | [Authentication and access](#authentication-and-access) | | Subprocessor list and change notification | [Subprocessors](#subprocessors) | | AI / model training and data use | [AI and model data use](#ai-and-model-data-use) | | Secrets and credential handling | [Secrets and credential handling](#secrets-and-credential-handling), [Authentication and access](#authentication-and-access) | | Rules of engagement for active testing | [Pentesting and active testing](#pentesting-and-active-testing) | | Compliance framework coverage | [Compliance framework mappings](#compliance-framework-mappings) | | GDPR data subject rights | [Data subject rights](#data-subject-rights) | | Vulnerability disclosure and incident intake | [Vulnerability disclosure](#vulnerability-disclosure) | | Audit reports and certifications | [Assurance status](#assurance-status) | | Business continuity and disaster recovery | [Business continuity and disaster recovery](#business-continuity-and-disaster-recovery). Ask about available RTO/RPO figures and DR test results through [Requesting evidence](/trust-and-coverage/trust-center/evidence-requests.md) | | Requesting audit reports, policies or a completed questionnaire | [Requesting evidence](/trust-and-coverage/trust-center/evidence-requests.md) | | Security awareness training programme | **Not published.** Request through [Requesting evidence](/trust-and-coverage/trust-center/evidence-requests.md) | ## Change log | Date | Change | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 2026-10-05 | Clarified the shared dashboard, router and identity control plane alongside customer processing stacks, and linked Entra access and network enforcement prerequisites. Other assurance sections retain their previous review dates. | | 2026-09-08 | Business continuity and disaster recovery published: backup plans and their retention, Multi-AZ and deletion protection, versioned object storage, deploy-by-sha rollback, Terraform reconstruction. RTO/RPO and DR test evidence directed to Security for availability confirmation. Assurance evidence request guidance published on [Requesting evidence](/trust-and-coverage/trust-center/evidence-requests.md). | | 2026-09-07 | First publication. Data flow, retention, encryption, authentication, subprocessors, AI data use, active-testing controls, framework mappings, data-subject rights, assurance status and the vendor-review index. Secrets and credential handling given its own section covering both the credentials you give Nullify and the secrets Nullify finds. |