Tuist Handbook

Appearance

Vulnerability scanning policy ​

  • Policy owner: Pedro Piñera Buendía
  • Effective Date: April 25, 2023

Purpose ​

This policy establishes the requirements for regular vulnerability scanning of Tuist GmbH's systems, applications, and dependencies to identify security vulnerabilities that could potentially be exploited by malicious actors. Regular vulnerability scanning is a critical component of Tuist's security program that helps ensure the confidentiality, integrity, and availability of our systems and data.

Scope ​

This policy applies to all systems, applications, and code repositories owned, operated, or maintained by Tuist GmbH that are business-critical and/or process, store, or transmit Confidential data. It applies to all employees, contractors, and third parties who manage or develop systems for Tuist GmbH.

Policy Statement ​

Tuist GmbH shall perform automated vulnerability scanning at least weekly on all Internet-exposed services and remote client applications. Dependency vulnerability scanning shall be performed continuously through automated tools integrated into our development pipeline.

Vulnerability Scanning Requirements ​

1. Frequency and Timing ​

  • Internet-Exposed Services: Weekly automated vulnerability scanning
  • Remote Client Applications: Weekly automated vulnerability scanning
  • Code Dependencies: Continuous monitoring via GitHub Dependabot and Snyk
  • Development Repositories: Scan on every pull request and at least daily for the main branch

2. Scanning Tools ​

Tuist GmbH uses the following tools for vulnerability scanning:

  • GitHub Dependabot: Configured to scan all GitHub repositories for vulnerable dependencies
  • Snyk: Used for dependency vulnerability scanning, application security testing, and container scanning
  • Sobelow: Used for detecting security vulnerabilities in Elixir code
  • Trivy: Used for scanning repositories and Docker images for vulnerabilities before merging into main
  • [Additional tools as applicable]: For network vulnerability scanning of Internet-exposed services

3. Types of Scanning ​

Vulnerability scanning shall include, at minimum:

  • Dependency Scanning: Identification of vulnerable third-party libraries and components using GitHub Dependabot, Snyk, and Trivy
  • Code Scanning: Detection of security issues in Elixir application code using Sobelow, with additional scanning by Snyk
  • Container Scanning: Examination of container images for vulnerabilities using Snyk and Trivy
  • Network Scanning: Assessment of Internet-exposed endpoints for configuration issues and known vulnerabilities
  • Repository Scanning: Comprehensive scanning of repositories using Trivy before merging into main branch

4. Scan Coverage ​

Vulnerability scans must cover:

  • All production applications and services
  • All staging environments accessible from the Internet
  • All third-party libraries and dependencies
  • All container images used in production environments
  • All remote client applications

5. Scan Configuration ​

At minimum, vulnerability scanning tools must be configured to:

  • Run automatically at the defined intervals
  • Include the latest vulnerability definitions and signatures
  • Produce detailed reports identifying the severity of findings
  • Generate alerts for critical and high severity findings
  • Minimize performance impact on production systems

6. Remediation Requirements ​

Vulnerabilities discovered during scanning shall be remediated according to the following timelines:

  • Critical: Within 7 days
  • High: Within 14 days
  • Medium: Within 30 days
  • Low: Within 90 days

Any deviation from these timelines requires a formal risk acceptance by the IT Manager and CTO.

7. False Positive Management ​

All potential false positives shall be:

  • Documented with justification for the false positive determination
  • Reviewed by security personnel
  • Periodically reassessed to ensure the status remains accurate

8. Documentation and Record Keeping ​

The following documentation must be maintained for vulnerability scanning:

  • Scan configurations and schedules
  • Scan results and reports
  • Remediation plans and status
  • Evidence of remediation for critical and high findings
  • Risk acceptances for any exceptions

All vulnerability scanning documentation shall be retained for a minimum of 2 years.

Tool-Specific Implementation ​

GitHub Dependabot Configuration ​

  1. Enabling: Dependabot is enabled on all GitHub repositories via the .github/dependabot.yml configuration file.
  2. Configuration:
    • Security updates are configured to run daily
    • Dependency version updates are configured to run weekly
    • Pull requests are automatically created for security vulnerabilities
  3. Review Process:
    • All Dependabot pull requests are reviewed within 48 hours
    • Critical vulnerabilities are prioritized for immediate review
  4. Documentation: Screenshots of Dependabot configurations and alert dashboards are captured quarterly for compliance evidence

Snyk Configuration ​

  1. Integration: Snyk is integrated with our GitHub repositories, CI/CD pipelines, and container registries.
  2. Scanning Frequency:
    • Code repositories are scanned continuously, with each commit/PR
    • Container images are scanned before deployment
    • Projects are monitored continuously for new vulnerabilities
  3. Alert Configuration:
    • Critical and high severity alerts trigger notifications to the security team
    • Weekly summary reports are generated and reviewed
  4. Documentation: Screenshots of Snyk dashboard showing scan configurations, coverage, and results are captured monthly for compliance evidence

Sobelow Configuration ​

  1. Integration: Sobelow is integrated into our CI/CD pipelines for Elixir projects.
  2. Scanning Frequency:
    • Code is scanned for vulnerabilities with each commit
    • CI/CD pipeline is configured to fail if security issues are detected
    • Configured to detect common vulnerabilities in Phoenix applications
  3. Alert Configuration:
    • Security findings are reported directly in the CI/CD pipeline
    • Developers are immediately notified of security issues
    • Merge is blocked until security issues are resolved
  4. Documentation: Screenshots of CI/CD configurations and Sobelow output are captured monthly for compliance evidence

Trivy Configuration ​

  1. Integration: Trivy is integrated into our CI/CD pipelines for repository and Docker image scanning.
  2. Scanning Frequency:
    • Repository contents are scanned for vulnerabilities before merging into main
    • Docker images are scanned for vulnerabilities during the build process
    • Configured to detect vulnerabilities in multiple layers of the application stack
  3. Alert Configuration:
    • Security findings are reported directly in the CI/CD pipeline
    • Pull requests are blocked from being merged if high or critical vulnerabilities are detected
    • Detailed reports are generated for remediation
  4. Documentation: Screenshots of Trivy scan configurations and results are captured monthly for compliance evidence

Evidence Collection and Reporting ​

To satisfy audit and compliance requirements, Tuist shall:

  1. Capture screenshots of vulnerability scanning tool configurations showing:

    • Scan schedules and frequency
    • Coverage of all in-scope systems
    • Alert configurations

  2. Generate and maintain vulnerability scanning reports:

    • Weekly summary of new vulnerabilities discovered
    • Monthly trending reports showing vulnerability remediation progress
    • Quarterly compliance reports showing adherence to remediation timelines

  3. Document remediation activities:

    • Tickets/issues created for vulnerability remediation
    • Evidence of patches or fixes applied
    • Verification scans confirming remediation

Roles and Responsibilities ​

IT Manager/Security Lead ​

  • Ensures vulnerability scans are scheduled and performed at required intervals
  • Reviews scanning reports and prioritizes remediation efforts
  • Approves exceptions and risk acceptances when necessary
  • Ensures compliance with this policy

Development Teams ​

  • Implement fixes for identified vulnerabilities within the required timeframes
  • Review and address Dependabot and Snyk alerts
  • Participate in vulnerability remediation planning
  • Document remediation actions

Operations Teams ​

  • Assist in implementing fixes for infrastructure or configuration vulnerabilities
  • Schedule scanning to minimize impact on production systems
  • Verify remediation effectiveness through follow-up scans

Exceptions ​

Any exceptions to this policy must be documented and approved by the IT Manager and the Chief Technology Officer. Exceptions shall be documented with:

  • The specific reason for the exception
  • The scope and duration of the exception
  • Any compensating controls implemented
  • Risk assessment of the exception
  • Approval signatures from authorized personnel

Compliance Monitoring and Enforcement ​

Compliance with this policy shall be monitored through:

  • Weekly review of scanning reports from Dependabot, Snyk, Sobelow, and Trivy
  • Monthly audit of remediation timelines
  • Quarterly review of scanning coverage and configuration for all security tools

Any known violations of this policy should be reported to the IT Manager. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment.

Policy Review ​

This policy shall be reviewed annually or when significant changes occur to Tuist's technology infrastructure.

Version History ​

The version history of this document can be found in Tuist's handbook repository.