Security Policy

1. Our Security Philosophy

PulsePR was designed around a data-minimization principle: the best way to protect sensitive data is to not collect it. We never clone Customer repositories. We access only the diff of explicitly tagged pull requests and delete that diff within 72 hours of review completion.

This means our security perimeter is substantially smaller than a typical SaaS product — there is no Customer source code database to protect at rest. But the data we do touch (PR diffs, review comments, account credentials, billing information) is handled with care proportional to its sensitivity.

2. Our Security Practices

2.1 Data in transit

All communication between clients, GitHub, and PulsePR infrastructure uses TLS 1.2 or higher. Webhook payloads from GitHub are validated using HMAC-SHA256 signature verification before processing.

2.2 Data at rest

PR diff data stored during active review is encrypted at rest using AES-256. Review comments, account data, and billing records are stored in encrypted databases with access controls. Encryption keys are managed through a dedicated key management service with automatic rotation.

2.3 Access controls

• All internal access to production systems requires multi-factor authentication
• Reviewer access is scoped to the specific PR assignment — no reviewer can browse other Customers' data or PR history
• Production database access is restricted to a named list of engineers and requires a time-limited credential with full audit logging
• We enforce the principle of least privilege throughout our infrastructure

2.4 GitHub App permissions

The PulsePR GitHub App is a GitHub App (not an OAuth App), which provides fine-grained permission scoping. We request:

• Pull requests: Read — to receive diffs and post review comments
• No access to repository contents, actions, secrets, webhooks, or administration

You can inspect PulsePR's exact permissions on the GitHub App listing. We will never request additional permissions without prior customer notification and explicit re-authorization.

2.5 Reviewer isolation

Each reviewer session is isolated: reviewers receive only the diff they are assigned, via a time-limited, single-use access token. Session data is destroyed upon review submission. Reviewers cannot access historical assignments, other Customers' PRs, or any metadata beyond the assigned diff and PR description.

2.6 Dependency and vulnerability management

We run automated dependency scanning on every build and receive automated alerts for known CVEs in our dependencies. Critical and high-severity findings block deployment. We conduct quarterly penetration testing with a third-party security firm.

2.7 Incident response

We maintain a documented incident response plan. In the event of a confirmed data breach affecting Customer PR content, we will notify affected Customers within 72 hours of confirmation, consistent with applicable data protection regulations.

3. Responsible Disclosure Program

We welcome security researchers who identify vulnerabilities in PulsePR. We ask that you:

1. Email details to [email protected] before any public disclosure
2. Give us reasonable time to investigate and remediate — we ask for a minimum of 90 days for complex vulnerabilities
3. Not access, modify, or exfiltrate data beyond what is necessary to demonstrate the vulnerability
4. Not disrupt service availability or perform denial-of-service testing
5. Not target Customers, reviewers, or any third parties — limit testing to your own accounts and our public-facing infrastructure

In return, we commit to:

• Acknowledging your report within 24 hours
• Keeping you informed of our investigation progress
• Not pursuing legal action against researchers who follow these guidelines in good faith
• Crediting researchers who identify confirmed vulnerabilities (unless you prefer to remain anonymous)

4. Scope

The following are in scope for the responsible disclosure program:

• The PulsePR web application and API (app.pulsepr.dev)
• The PulsePR GitHub App and webhook endpoints
• Authentication and session management
• Authorization controls (e.g., can a reviewer access another Customer's PR?)
• Data exposure or injection vulnerabilities

5. Out of Scope

The following are out of scope and should not be tested:

• Denial of service or rate-limiting attacks
• Social engineering or phishing attacks against PulsePR employees or reviewers
• Physical security
• Vulnerabilities in third-party services we depend on (report those to the respective vendor)
• Issues requiring unlikely user interaction (e.g., a user must already have admin access)
• Best-practice recommendations without a demonstrated exploitable impact

6. Bug Bounty

We are in the process of establishing a formal bug bounty program. At this time we do not offer monetary rewards, but we do offer public credit (with your permission) and our sincere thanks. Researchers who identify critical vulnerabilities during our beta period will be prioritized for compensation once the program launches.

7. How to Report

Email [email protected] with:

• A description of the vulnerability and its potential impact
• Steps to reproduce, including any relevant request/response pairs
• Any supporting evidence (screenshots, PoC code) — please encrypt sensitive attachments with our PGP key if the content itself is sensitive

For general security questions or concerns that are not vulnerability reports, use [email protected] as well.

8. PGP Key

If your report contains sensitive data (e.g., a proof of concept that demonstrates data access), please encrypt it using our security team's PGP key. Email [email protected] to request the current key fingerprint before sending encrypted material.

9. Compliance and Certifications

PulsePR is currently pursuing SOC 2 Type II certification. Our GitHub App is verified by GitHub and listed on the GitHub Marketplace. We operate under the bilateral NDA that is included with all subscriptions, which provides contractual data protection guarantees in addition to our technical controls.

For Enterprise clients with specific compliance requirements (HIPAA, FedRAMP, PCI-DSS), contact [email protected] to discuss your requirements. Note that our zero-source-code-storage architecture substantially reduces the compliance surface area for most regulated industries.

10. Policy Updates

This policy is reviewed and updated quarterly. Material changes will be announced on our status page and by email to active subscribers. Security researchers actively engaged in a disclosure will be notified of any changes that affect the scope of their work.