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 — [e-mail]
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 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 and 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. 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 uses OIDC, with workspace membership, roles and lifecycle governed separately. Entra-only sign-in and 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). 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 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.

Vulnerability disclosure

Report a vulnerability in the Nullify platform to [e-mail]. The intake process, our commitments, and the safe-harbour terms are on the Security 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. 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
Where customer data is stored, and residency	Where your source code lives, and for how long, Subprocessors
Retention and deletion schedules	Retention
Encryption at rest and in transit	Encryption
Authentication, SSO, least privilege	Authentication and access
Subprocessor list and change notification	Subprocessors
AI / model training and data use	AI and model data use
Secrets and credential handling	Secrets and credential handling, Authentication and access
Rules of engagement for active testing	Pentesting and active testing
Compliance framework coverage	Compliance framework mappings
GDPR data subject rights	Data subject rights
Vulnerability disclosure and incident intake	Vulnerability disclosure
Audit reports and certifications	Assurance status
Business continuity and disaster recovery	Business continuity and disaster recovery. Ask about available RTO/RPO figures and DR test results through Requesting evidence
Requesting audit reports, policies or a completed questionnaire	Requesting evidence
Security awareness training programme	Not published. Request through Requesting evidence

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.
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.