-
Notifications
You must be signed in to change notification settings - Fork 0
Security CI CD
This document describes TrueHour's comprehensive security and code quality CI/CD pipeline.
TrueHour implements a multi-layered security approach with automated scanning, linting, and SBOM generation to ensure code quality and security compliance.
Workflow: .github/workflows/security-scan.yml
Schedule:
- On push to
mainanddevelopbranches - On pull requests
- Daily at 2 AM EST (7 AM UTC)
- Manual dispatch
Purpose: Static Application Security Testing
Scans for:
- Security vulnerabilities
- OWASP Top 10 issues
- Python-specific security issues
- Dockerfile security issues
Rulesets:
p/security-auditp/owasp-top-tenp/pythonp/dockerfile
Output: SARIF format uploaded to GitHub Security tab
Purpose: Deep semantic code analysis
Scans for:
- Security vulnerabilities
- Code quality issues
- Common programming errors
Languages: Python
Queries: security-extended, security-and-quality
Output: SARIF format uploaded to GitHub Security tab
Checks Python dependencies against known security vulnerabilities database.
safety check --file backend/requirements.txtScans Python code for common security issues.
bandit -r backend/app -llAudits Python packages for known vulnerabilities.
pip-audit --require backend/requirements.txtOutputs: JSON reports retained for 30 days
Purpose: Container image vulnerability scanning
Scans for:
- OS package vulnerabilities
- Application library vulnerabilities
- Container configuration issues
Severity Levels: CRITICAL, HIGH, MEDIUM
Images Scanned:
-
truehour-api(backend) -
truehour-frontend(frontend)
Output: SARIF format uploaded to GitHub Security tab
Purpose: Dockerfile best practices linting
Checks for:
- Dockerfile best practices
- Security issues
- Build optimization opportunities
Severity: Warning threshold
Output: SARIF format uploaded to GitHub Security tab
Purpose: Secret scanning
Scans for:
- API keys
- Passwords
- Tokens
- Private keys
- Credentials in code and git history
Scope: Full git history (fetch-depth: 0)
Purpose: Comprehensive dependency vulnerability scanning
Features:
- Known CVE detection
- Experimental analyzers enabled
- Fails on CVSS >= 7
Output: Multiple formats (HTML, XML, JSON, SARIF)
Retention: 30 days
All security findings are:
- Uploaded to GitHub Security tab (SARIF format)
- Available as workflow artifacts
- Summarized in workflow summary
-
GitHub Security Tab: Navigate to
Security > Code scanning alerts - Workflow Artifacts: Download from Actions run
- Workflow Summary: View summary in Actions run page
Workflow: .github/workflows/sbom-generation.yml
Schedule:
- On push to
mainanddevelopbranches (when dependencies change) - On pull requests
- On releases
- Weekly on Sundays at 3 AM EST (8 AM UTC)
- Manual dispatch
TrueHour generates SBOMs in two industry-standard formats:
- CycloneDX - OWASP standard, optimized for security use cases
- SPDX - ISO/IEC 5962:2021 standard
Tools: cyclonedx-bom, syft, pip-licenses
Generated Files:
-
backend-sbom-cyclonedx.json- CycloneDX format -
backend-sbom-spdx.json- SPDX format -
backend-licenses.json- License information (JSON) -
backend-licenses.md- License information (Markdown)
Tool: Anchore Syft
Generated Files (per container):
-
{container}-sbom-cyclonedx.json- CycloneDX format -
{container}-sbom-spdx.json- SPDX format -
{container}-sbom.txt- Human-readable table
Containers:
truehour-apitruehour-frontend
When: On release events
What: Cryptographically signs SBOMs and attaches them to container images
Tool: GitHub Attestation (actions/attest-sbom@v1)
Purpose: Provides verifiable proof of SBOM authenticity
Tool: Grype (by Anchore)
Scans generated SBOMs for vulnerabilities:
- Severity cutoff: HIGH
- Non-blocking (informational)
- Artifacts: 90 days
- Release Attachments: Permanent
- Container Attestations: Permanent (attached to image)
Download from workflow artifacts:
gh run download <run-id> -n python-sbom
gh run download <run-id> -n truehour-api-sbom
gh run download <run-id> -n truehour-frontend-sbom# Download SBOM archive from latest release
curl -LO https://github.com/FliteAxis/TrueHour/releases/latest/download/truehour-sbom-v*.tar.gz
tar -xzf truehour-sbom-v*.tar.gz# Verify SBOM attestation for container image
gh attestation verify oci://ghcr.io/fliteaxis/truehour-api:latestWorkflow: .github/workflows/lint.yml
Schedule:
- On push to
mainanddevelopbranches - On pull requests
- Manual dispatch
-
Black - Code formatter
- Line length: 120
- Target: Python 3.12
- Config:
pyproject.toml
-
isort - Import sorting
- Profile: black
- Config:
pyproject.toml
-
Flake8 - Style guide enforcement
- Max line length: 120
- Config:
.flake8
-
Pylint - Code quality analysis
- Fail threshold: 8.0/10
- Config:
pyproject.toml
-
mypy - Static type checking
- Python version: 3.12
- Config:
pyproject.toml
# Format code
black backend/
isort backend/
# Lint
flake8 backend/
pylint backend/app
mypy backend/app-
HTMLHint - HTML linting
- Config:
.htmlhintrc
- Config:
-
HTML5 Validator - HTML validation
- Standard: W3C HTML5
# Install
npm install -g htmlhint
# Lint
htmlhint frontend/**/*.html-
hadolint - Dockerfile linter
- Severity: warning
- Ignored rules: DL3008, DL3013
-
Checkov - Infrastructure as Code scanner
- Framework: dockerfile
# hadolint (via Docker)
docker run --rm -i hadolint/hadolint < backend/Dockerfile
# Checkov
pip install checkov
checkov -f backend/Dockerfile-
docker-compose validation
docker-compose -f infrastructure/docker-compose.ghcr.yml config
-
Checkov - IaC scanner
- Framework: docker_compose
docker-compose -f infrastructure/docker-compose.ghcr.yml config
checkov -f infrastructure/docker-compose.ghcr.ymlConfig: Inline in workflow
Rules:
- Max line length: 120
- Document start: disabled
- Truthy values: true, false, on, off
pip install yamllint
yamllint .github/workflows/ infrastructure/Config: .markdownlint.json
Rules:
- Line length: 120 (code blocks and tables exempted)
- HTML allowed
- Sibling duplicate headers allowed
npm install -g markdownlint-cli2
markdownlint-cli2 "**/*.md"Severity: Warning
# Via package manager
apt-get install shellcheck # Debian/Ubuntu
brew install shellcheck # macOS
# Lint all shell scripts
find . -name "*.sh" -exec shellcheck {} \;Configuration: renovate.json
Platform: Renovate Bot
Schedule: Weekly on Mondays before 6 AM EST
- Python packages (
requirements.txt) - Docker base images
- GitHub Actions
- Docker Compose service images
- Docker base images - Monthly schedule
- Python dependencies (non-major) - Weekly, grouped
- Python dependencies (major) - Monthly, separate PRs
- GitHub Actions - Weekly, grouped, auto-merge
- FastAPI ecosystem - Updated together
Auto-merge enabled for:
- Patch updates for Python dependencies
- Patch updates for GitHub Actions
- Non-major updates passing all checks
Conditions:
- All CI checks pass
- Minimum release age: 3 days
- Stability days: 3
Priority: High (10)
Labels: security, dependencies
Schedule: At any time (not restricted)
Auto-merge: Enabled for patch versions
Semantic commit: fix(deps): ... [security]
{
"schedule": ["before 6am on monday"],
"timezone": "America/New_York",
"prConcurrentLimit": 10,
"stabilityDays": 3,
"minimumReleaseAge": "3 days"
}Navigate to Issues tab to find the Renovate Dependency Dashboard issue, which provides:
- Pending updates
- Rate-limited updates
- Errored updates
- Manual merge required updates
| File | Purpose | Tool |
|---|---|---|
| N/A | Semgrep uses cloud rulesets | Semgrep |
| N/A | CodeQL uses built-in queries | CodeQL |
| File | Purpose | Tool |
|---|---|---|
.flake8 |
Flake8 configuration | Flake8 |
pyproject.toml |
Black, isort, Pylint, mypy | Multiple |
.htmlhintrc |
HTML linting rules | HTMLHint |
.markdownlint.json |
Markdown linting | markdownlint |
| File | Purpose | Tool |
|---|---|---|
renovate.json |
Dependency updates | Renovate |
-
DL3008- Pin versions in apt-get (acceptable for base images) -
DL3013- Pin versions in pip (using requirements.txt)
-
C0111- Missing docstring (acceptable for small functions) -
R0903- Too few public methods (acceptable for models) -
R0913- Too many arguments (acceptable for FastAPI endpoints)
-
Run linters locally before committing:
black backend/ && isort backend/ flake8 backend/ pylint backend/app -
Review security findings in pull requests
-
Update dependencies promptly when Renovate creates PRs
-
Address vulnerabilities flagged by security scans
-
Test SBOM generation for significant dependency changes
-
Review Renovate PRs weekly
-
Monitor security alerts in GitHub Security tab
-
Update security policies as threats evolve
-
Verify SBOM attestations on releases
-
Archive security reports for compliance
- OWASP Top 10 - Covered by Semgrep and CodeQL
- CWE - Common Weakness Enumeration checks via multiple tools
- NIST SP 800-53 - Security controls via SAST/DAST
- SBOM Standards - CycloneDX 1.5, SPDX 2.3 (ISO/IEC 5962:2021)
All security scans produce:
- SARIF files - Machine-readable results
- JSON reports - Detailed findings
- GitHub Security alerts - Centralized dashboard
- Workflow artifacts - Historical records (30-90 days)
Issue: False positives in security scans
Solution:
- Review the specific finding
- If legitimate, add exception in code with justification
- If tool error, update
.github/workflows/security-scan.ymlto exclude
Issue: Code doesn't pass linting
Solution:
# Auto-fix formatting
black backend/
isort backend/
# Review remaining issues
flake8 backend/Issue: SBOM generation fails
Solution:
- Check if all dependencies are properly specified
- Verify container builds successfully
- Review Syft/CycloneDX versions in workflow
Issue: No Renovate PRs appearing
Solution:
- Check Renovate Dashboard issue
- Verify
renovate.jsonsyntax - Review Renovate logs in Actions tab
- DAST (Dynamic Application Security Testing) with OWASP ZAP
- Container runtime security monitoring
- License compliance automation
- Security metrics dashboard
- Automated vulnerability remediation
- Supply chain security attestations (SLSA)
- Fuzzing tests for API endpoints
- Penetration testing automation
- Chaos engineering for security
- Red team automation
- Semgrep Rules
- CodeQL Query Help
- Trivy Documentation
- CycloneDX Specification
- SPDX Specification
- Renovate Docs
For security concerns or questions about the CI/CD pipeline:
- Security Issues: Create a Security Advisory
- General Questions: Open an Issue
- Contribution: See Contributing Guide
π View on GitHub | π³ Docker Hub
π Report Issue | π¬ Discussions
License: MIT License | Copyright (c) 2024-2025 FliteAxis
π Getting Started
π¦ Deployment
π§ Development
π Security
- Security Setup Guide
- Security CI/CD Pipeline
- Code Quality & Linting
- SBOM Management
- Vulnerability Scanning
π Dependencies
π³ Docker
π Reference
π Links