Welcome to our Security Policy. This document outlines our standards and best practices to ensure secure development, responsible vulnerability disclosure, and effective handling of security updates across all our repositories.

• Input Validation: All external input is validated, sanitized, and/or escaped to prevent injection attacks (e.g., SQLi, XSS, Command Injection).
• Output Encoding: Data is properly encoded before being rendered in user interfaces or passed to other systems to prevent XSS and other injection flaws.
• Principle of Least Privilege: Code and services run with the minimum permissions necessary to perform their functions.
• Error Handling: Implement robust error handling that does not expose sensitive information in error messages.
• Authentication & Authorization: Utilize strong, industry-standard authentication mechanisms. Enforce strict authorization checks for all actions and data access.
• Session Management: Employ secure session management techniques, including secure cookie flags (HttpOnly, Secure, SameSite) and timely session expiration.
• Cryptography: Use strong, up-to-date cryptographic algorithms and protocols for data in transit and at rest. Avoid custom cryptographic implementations.
• Always use HTTPS for all external communication. Avoid transmitting sensitive data over HTTP.

• Vulnerability Scanning: Regularly scan project dependencies for known vulnerabilities using tools like GitHub Dependabot or OWASP Dependency-Check.
• Update Policy: Keep dependencies updated to their latest secure versions. Establish a process for timely patching of vulnerable dependencies.
• Minimal Dependencies: Only include dependencies that are necessary for the project's functionality to reduce the attack surface.
• Use released versions from trusted branches or GitHub Releases; avoid pulling from feature branches or forks.

• No Hardcoded Secrets: Never hardcode secrets (API keys, passwords, tokens, private keys) directly in source code, configuration files, or build scripts.
• Secure Storage: Utilize approved secrets management solutions (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GitHub Encrypted Secrets) for storing and accessing secrets.
• Rotation: Regularly rotate secrets according to defined policies.
• Least Privilege for Secrets: Grant access to secrets on a need-to-know basis with the minimum required permissions.

• Enable branch protection rules on all default branches:
  • Require PR reviews before merging
  • Require status checks to pass
  • Restrict who can push to matching branches
• Enable signed commits enforcement where possible
• Use CODEOWNERS files to define clear ownership for code review
• Turn on GitHub's Security Features:
  • Secret scanning
  • Code scanning
  • Dependabot alerts & updates

• Infrastructure as Code (IaC) Security: Securely configure IaC templates (e.g., Terraform, CloudFormation, Ansible). Lint and scan IaC for security misconfigurations before deployment.
• Secure Defaults: Configure services and infrastructure with secure defaults. Harden systems by disabling unnecessary services and features.
• Network Security: Implement network segmentation, firewalls, and intrusion detection/prevention systems where appropriate.
• Logging and Monitoring: Implement comprehensive logging and monitoring to detect and respond to security incidents. Ensure logs are securely stored and regularly reviewed.

• Minimal Base Images: Use minimal, trusted base images for containers.
• Image Scanning: Scan container images for vulnerabilities before deployment and monitor them at runtime.
• Least Privilege in Containers: Run container processes with non-root users and minimal privileges.
• Secure Registries: Use secure, private container registries.

• Code Reviews: All code changes must undergo a security-focused code review by at least one other developer.
• Protected Branches: Utilize protected branches in Git repositories to enforce code review, status checks, and prevent direct pushes to critical branches (e.g., main, master, release/*).
• Static Application Security Testing (SAST): Integrate SAST tools into the CI/CD pipeline to identify potential vulnerabilities in code before deployment.
• Dynamic Application Security Testing (DAST): Perform DAST on running applications, especially in staging environments, to identify runtime vulnerabilities.
• Security Training: Provide regular security awareness and secure coding training for all developers and relevant personnel.

We take security vulnerabilities seriously. If you believe you've discovered a potential vulnerability, please follow the steps below:

• Email us at [email protected] with detailed information, including:

  • Affected repository and version
  • Steps to reproduce the issue
  • Impact and potential mitigation (if known)
  • Your contact information (for coordinated disclosure)

• Alternatively, refer to our official disclosure policy at:
  📄 https://www.pbs.org/.well-known/security.txt

To help us understand and address the vulnerability quickly, please include the following details in your report:

• A clear description of the vulnerability, including the type of vulnerability (e.g., XSS, SQLi, RCE).
• The specific product, repository, URL, or component affected.
• Step-by-step instructions to reproduce the vulnerability.
• Any proof-of-concept code, scripts, or screenshots.
• The potential impact of the vulnerability.
• Any suggestions for remediation (if you have them).

• Do not open a GitHub issue for security vulnerabilities.
• Do not post sensitive information publicly.
• Do not test vulnerabilities in production environments without permission.

• We will acknowledge receipt of your vulnerability report within 3 business days.
• We will investigate the reported vulnerability and aim to provide an initial assessment of its validity and severity within 5 business days.
• We will maintain open communication with you throughout the process, providing updates on our progress.
• We will work to remediate validated vulnerabilities in a timely manner, based on their severity.
• We will notify you when the vulnerability has been fixed.
• We appreciate your efforts and will, where appropriate, publicly acknowledge your contribution (with your permission).

We consider security research and vulnerability disclosure activities conducted in accordance with this policy to be authorized. We will not initiate legal action against individuals who report vulnerabilities in good faith and adhere to this policy. We will work with you to understand and quickly resolve the issue, and we will not pursue or support any legal action related to your research if you comply with this policy.

We are committed to maintaining a secure codebase and responding to security concerns promptly.

1. Triage & Reproduce:

   • Vulnerability is confirmed and severity is assessed.
   • We will attempt to reproduce and validate the reported vulnerability.
   • Validated vulnerabilities will be prioritized based on their severity (e.g., using CVSS - Common Vulnerability Scoring System), potential impact, and the systems affected.

2. Fix & Validate:

   • A secure patch is developed, tested, and peer-reviewed.
   • After a fix is deployed, we will verify that the vulnerability has been successfully remediated.

3. Coordinate Disclosure (if required):

   • Work with the reporter on timeline and communication (for critical issues).

4. Release & Communicate:

   • A patched release is published (via GitHub Releases or package manager).
   • Users are notified via Release Notes and security advisories (.github/SECURITY.md and GitHub Advisory Database).

• Regular Releases: For most vulnerabilities, fixes will be included in the next planned regular release or patch cycle for the affected software or service.
• Hotfixes/Emergency Releases: For critical or high-severity vulnerabilities that pose an immediate threat, we may issue an emergency hotfix or out-of-band release.
• Security Advisories: For significant vulnerabilities, especially those affecting publicly available software or libraries, we may publish security advisories.

For supported branches, we backport security fixes to:

• The latest release
• Previous LTS (Long-Term Support) branches, if applicable

Legacy or EOL (End-of-Life) branches will not receive patches, and users are encouraged to upgrade to a maintained version.

We greatly value the efforts of the security research community and welcome responsible disclosures. Recognition may be provided in our Hall of Fame (if applicable) or in public release notes, subject to permission.

• Primary Security Contact: [email protected]
• Public PGP Key (optional): Link to .well-known/security.txt
• Incident Response SLA:
  • Acknowledgement: 3 business days
  • Resolution Target: 30 business days

Thank you for helping us keep our ecosystem safe!

Last updated: 2023-11-15