Skip to content

Security Practices

Fencer is a security platform, and we hold ourselves to the same standard we help our customers achieve. We maintain a formal information security program with documented policies reviewed and approved annually by senior management. Fencer is SOC 2 Type II compliant and has been audited by an independent third-party auditor. For compliance documents and certifications, visit our Trust Center. This page provides a high-level overview of how we protect the platform and your data.

Fencer does not store, retain, or persist your source code. When a code scan runs, the target repository is cloned into an isolated, ephemeral environment where it is analyzed by our scanning engines. Once the scan completes, the source code is automatically deleted. Only the scan results (vulnerability findings, metadata, and summary statistics) are retained in your Fencer account.

This applies to all scan triggers: webhook-driven scans from pull requests, manually initiated scans, and scheduled scans. In every case, the source material is discarded immediately after processing.

All scanning and processing workloads run on ephemeral, isolated infrastructure that is provisioned on demand for each scan and automatically destroyed when the scan completes. Source code, configuration data, and any other customer material accessed during a scan exist only for the duration of that scan. Nothing persists in the scanning environment afterward.

This applies across all scan types: code, cloud infrastructure, application, container, and network scanning. Each scan runs in its own isolated context with no shared state between scans or between customers.

All customer data is encrypted at rest using AES-256 encryption with keys managed through a dedicated key management service. Encryption keys are rotated at least annually.

All data in transit is encrypted end-to-end using strong protocols, including communication between internal services, external integrations, and customer-facing interfaces.

Customer data is hosted on AWS in the United States, replicated across multiple availability zones for redundancy and disaster recovery.

Each customer organization’s data is logically separated at the database level using a unique identifier. This separation is enforced at the API layer: every request is scoped to an authenticated tenant, and all queries include the tenant identifier. No customer can access another customer’s data through any API path.

Access to Fencer’s internal systems is governed by role-based access control and the principle of least privilege. Multi-factor authentication is required for all personnel.

Employee access to production systems is disabled by default. When access is required, it is granted through a documented approval process with time-limited scope and reviewed on a case-by-case basis.

Access rights across all systems are reviewed quarterly. Upon offboarding, system and physical access is revoked within one business day.

All code changes undergo peer review by someone other than the author before merging. Static application security testing runs automatically as part of the CI/CD pipeline, and identified vulnerabilities are addressed before release.

Development, testing, and production environments are strictly separated with independent access controls. All changes to production require human approval, enforced through automated mechanisms.

Fencer continuously scans its own infrastructure and applications for vulnerabilities using a combination of automated scanning tools. Findings are tracked against defined remediation SLAs.

Independent penetration testing is performed at least annually.

Fencer follows a defense-in-depth approach with multiple layers of security controls. Web application firewalls protect all external-facing services. Network traffic is restricted by default-deny rules, and only explicitly authorized traffic is permitted. Intrusion detection and prevention systems monitor for suspicious or anomalous activity.

Customer data is backed up daily with automated, encrypted backups replicated to a separate geographic region within the United States. Infrastructure is defined as code, enabling rapid recovery to the same or an alternate cloud environment.

Recovery procedures are tested annually. The target is to restore full operations within 24 hours of a disaster.

Fencer maintains a documented incident response plan with defined severity levels and escalation procedures. Security incidents are investigated within 48 hours of detection. Post-mortem reviews are conducted after every incident to identify root causes and prevent recurrence. Affected customers are notified when incidents impact their data.

Fencer uses AI-powered features to help you triage, prioritize, and remediate security findings faster. Customer data is never used to train third-party AI models. When AI features process your data, it is used solely to generate results for your organization and is not retained by any third-party model provider.

We welcome vulnerability reports from the security community. If you discover a security issue affecting the Fencer platform, please report it to security@fencer.dev.

We commit to responding within 10 business days and will not pursue legal action against researchers who test responsibly, stay within scope, and follow applicable laws.