Security at BuildPulse

1. Our Approach to Security

Security is foundational to how we build and operate BuildPulse. We process test results, CI metadata, and source-code signals on behalf of engineering teams, and we treat that data as confidential. We apply defense-in-depth, the principle of least privilege, and secure-by-default engineering practices across our platform.

This page describes the technical and organizational measures we use to protect customer data. It is provided for general informational purposes, is not part of any contract, and may change as our program evolves. The contractual security commitments that apply to your use of the Services are set out in our Terms of Service and Data Processing Agreement.

2. Infrastructure and Hosting

BuildPulse runs entirely on Amazon Web Services (AWS) in the United States. We rely on AWS’s physically secure, audited data centers (SOC 1/2/3, ISO 27001, and more) for the underlying compute, storage, and network infrastructure.

• Application services run on AWS ECS Fargate and AWS Lambda within a private virtual network (VPC).
• Primary application data is stored in Amazon DocumentDB clusters that reside in private subnets with no direct public internet access.
• Databases and internal services are reachable only from within the VPC; administrative access is brokered through hardened, access-controlled bastion mechanisms rather than public endpoints.
• Network access is restricted using security groups, subnet isolation, and least-privilege routing.

3. Encryption

In transit. All data exchanged with the Services travels over encrypted connections using TLS. Connections to our databases and between internal services are likewise encrypted.

At rest. Object storage, DynamoDB tables, and related backups use encryption at rest with strong, industry-standard algorithms (such as AES-256), with keys managed through AWS Key Management Service where applicable. Our primary DocumentDB clusters reside in private subnets with no public endpoints, require TLS for all connections, and are further restricted by security groups and least-privilege access; we continue to evaluate enabling native DocumentDB storage encryption as a hardening improvement.

Secrets. Application secrets and credentials are stored in managed secret stores, are not committed to source control, and are made available to services only as needed at runtime.

4. Access Control and Authentication

Customer authentication is handled through Amazon Cognito. Account passwords are never stored in plaintext, and we support modern authentication flows including OAuth 2.1 with PKCE for programmatic access such as the MCP server.

Internally, access to production systems and customer data is restricted to a limited number of authorized personnel who require it to operate the Services. We enforce least-privilege, scoped IAM roles, require multi-factor authentication for administrative access, and log administrative actions. Access is reviewed and revoked promptly when no longer needed.

Within your organization, BuildPulse provides role-based access controls so you can manage which of your users can view or administer your data.

5. Data Segregation and Tenant Isolation

BuildPulse is a multi-tenant service. Customer data is logically segregated and scoped to the owning organization, and every data-access path is constrained by organization and repository identifiers so that one customer cannot access another customer’s data. Production data is kept separate from development and testing environments, and we do not use customer data in non-production environments.

6. How We Handle Your Code and CI Data

BuildPulse is designed to operate on test results, coverage reports, and CI metadata — not to store full copies of your source code. Our GitHub integration is delivered through a GitHub App that requests narrowly scoped permissions, and we ask only for the access required to deliver the features you enable.

Access tokens for connected services such as GitHub, Slack, and Jira are stored encrypted and used solely to provide the integrations you authorize. You can revoke BuildPulse’s access at any time from the relevant provider, which terminates our ability to act on your behalf.

7. Application and Vulnerability Management

We build security into our development lifecycle:

• Code changes are version-controlled, peer-reviewed, and pass automated checks — including AI-assisted code review and security review — before being merged.
• We monitor our dependencies for known vulnerabilities and apply patches and upgrades on a risk-prioritized basis.
• Infrastructure is managed as code (Terraform), enabling consistent, reviewable, and auditable configuration.
• We log and monitor application and infrastructure activity to detect anomalous or unauthorized behavior.

8. Availability, Backup, and Resilience

Our infrastructure is deployed across multiple AWS availability zones to tolerate the failure of any single zone. Databases are backed up regularly. Encrypted object storage and DynamoDB point-in-time recovery complement DocumentDB automated snapshots. We maintain operational practices designed to restore service and recover data in the event of a disruption. While we engineer for high availability, the Services are provided on an “as available” basis as described in our Terms of Service.

9. Incident Response and Breach Notification

We maintain an incident-response process for identifying, investigating, containing, and remediating security events. In the event of a personal-data breach affecting customer data, we will notify affected customers without undue delay and consistent with our Data Processing Agreement and applicable law, and we will provide information reasonably necessary for customers to meet their own notification obligations.

10. Compliance and Sub-Processors

We are pursuing SOC 2 Type I attestation (Security) and continue to mature our security program toward Type II and other recognized industry frameworks. For data-protection compliance — including the GDPR and applicable U.S. state privacy laws — please see our Privacy Policy and our Data Processing Agreement, which describes the safeguards we apply to international transfers and our use of sub-processors. A current list of sub-processors is available on request.

11. Responsible Disclosure

We welcome reports from security researchers. If you believe you have found a security vulnerability in BuildPulse, please report it to us at security@buildpulse.io and give us a reasonable opportunity to investigate and remediate before any public disclosure. We ask that you avoid privacy violations, data destruction, and service degradation while testing, and that you only test against accounts and data you own or are authorized to access. We do not pursue legal action against researchers who act in good faith and in accordance with this guidance.

12. Contact

For security questions, to request our detailed security documentation, or to report a vulnerability, contact us at security@buildpulse.io.