Genesis Security Audit Procedures
Prepared for: Chief Security Officer Date: March 15, 2026 Repository:genesis-computing-ai/genesis-agents (private)
Executive Summary
Genesis maintains a layered security scanning pipeline that operates at three levels: source code analysis (ruff security and correctness rules), container image vulnerability scanning of built images (which also covers Python and Node.js dependency CVEs), and continuous monitoring of published Docker images. All scans run automatically in CI/CD via GitHub Actions; depending on the check, failures block PR merges and/or GA release promotion. Failures trigger Slack notifications and automated triage agents that analyze root causes and propose fixes.Security Controls Overview
Detailed Procedure: Container Image Vulnerability Scanning (Build-Time)
Workflow:Check: Docker Build (build-docker-test.yml)
Scanner: Trivy (Aqua Security), via composite action .github/actions/trivy-scan/
When It Runs
What It Does
- Builds the full Docker image (base + app layers) from current source
- Runs a container health check (server must report ready within 180s)
- Scans the built image with Trivy for HIGH and CRITICAL library vulnerabilities
- Fails the workflow (exit code 1) if any vulnerability is found
- On failure, posts to the
#engineering-check-engineSlack channel and dispatches the triage agent
Scan Configuration
Why Library-Only Scanning
During evaluation, unfiltered scanning reported ~51 HIGH/CRITICAL CVEs, of which ~37 were OS-level (linux kernel headers, system Python packages, glibc, gnupg). These packages are:- Not directly invocable by application code
- Present as build dependencies, not runtime attack surface
- Managed by the base image’s OS vendor, not by us
library reduces findings to only actionable application dependency vulnerabilities — the packages we directly control and can upgrade.
Scanner Selection Rationale
We evaluated three open-source scanners (Trivy, Grype, Docker Scout) against a commercial reference vulnerability report containing 21 HIGH/CRITICAL CVEs:
Trivy was selected over Grype despite marginally lower detection rate because:
- 3x larger community (32K vs 11.5K GitHub stars) — better support ecosystem
- All-in-one scanning (vulns + IaC + secrets + licenses) if we expand scope later
- Official GitHub Action with 7-minute setup in CI
- Every CVE Trivy missed, Grype also missed (shared blind spot in transitive dependency attribution)
Detailed Procedure: Published Image Security Monitoring
Workflow:Check: Image Security (check-image-security.yml)
Trigger: Trigger: Security Scans (trigger-security-scans.yml)
Scanner: Trivy (Aqua Security), via composite action .github/actions/trivy-scan/
Purpose
New CVE advisories are published several times a day across the Python and Node.js ecosystems, and advisories relevant to packages in our dependency tree appear several times a week. A vulnerability may have no known CVE when the image is built but be disclosed hours later. While build-time scanning catches vulnerabilities at the point of code change, published image monitoring continuously re-scans the images already deployed in production (GA), staging (RC), and development (edge) to catch these newly disclosed CVEs promptly.When It Runs
The scheduled trigger (
trigger-security-scans.yml, cron 30 */2 * * *) automatically resolves the latest release branch and GA tag, then dispatches three independent check-image-security.yml runs — one per scope. The RC build workflow (release-create-rc.yml) additionally dispatches a security scan immediately after the Docker image is published to GHCR.
What It Does
- Resolves the correct GHCR image reference for the target scope
- Verifies the image exists in GHCR (gracefully skips if not yet published)
- Scans the published image with Trivy for HIGH and CRITICAL vulnerabilities
- On failure, posts to the
#engineering-check-engineSlack channel and dispatches the triage agent
Scan Scopes
Dashboard Integration
The release dashboard reads this workflow’s run history to display per-scope [SEC] indicator lights, showing at a glance whether each scope’s published image is clean.Detailed Procedure: Source Code Lint Audit
Workflow:Check: Lint (check-lint.yml)
Runs on: Every pull request to main + every push to main
What It Does
This workflow runs ruff with Bandit security (S-series) and Pylint error (PLE-series) rules on all source code ingenesis_bots/ and enforces a ratchet policy — the number of issues can only go down, never up. Any increase fails the CI.
Dependency vulnerability scanning (pip-audit, npm-audit) was previously part of a separate
security-audit.yml workflow but has been removed. Dependency CVEs are now caught by the Trivy container image scans, which detect vulnerable Python and Node.js libraries in the built Docker image.
Ratchet Mechanism
Results are recorded insecurity_audit/audit.csv after each run on main. Each subsequent run compares against this baseline. A PR that introduces even one new security or correctness violation is blocked. Reductions are always accepted.
Accepted Risk Process
When a ruff finding is a false positive, a# noqa: S### comment (with justification) is added to the flagged line. For container image CVEs whose fix cannot be installed, a .trivyignore entry records why carrying the vulnerability is acceptable, with a ticket.
An accepted risk does not stay accepted by default. Every two hours, the review-ignore-file job in the Main Check: Image Security run re-derives, for each suppressed CVE, what holds the fix back: the parent package whose requirements refuse the fixed version, or the compiled binary the vulnerable library sits inside. It reads the newest release of each from the package registry, scans a newly released binary with Trivy, and opens a pull request when the fix has become installable or the suppression no longer suppresses anything. While such a pull request waits for a decision the run fails, which turns the security light on the release dashboard red until it is merged or declined. Its report states, per CVE, exactly why we are not fixing it yet. The procedure is documented in docs/security/MANAGING_TRIVY_IGNORE.md.
Code Security Rules
The code audit enforces 78 Bandit-derived security rules (S-series) covering: hardcoded credentials, insecure crypto, SQL injection, shell injection, XML vulnerabilities, insecure SSL/TLS, and more. It also enforces 30+ Pylint error rules (PLE-series) for critical code correctness issues. Full rule listing is maintained insecurity_audit/security-audit.md.
Failure Notifications and Automated Triage
Slack Notifications
When any check-engine workflow fails, a structured notification is posted to the#engineering-check-engine Slack channel via the reusable reusable-check-engine-failure.yml workflow. The notification includes the check name, branch, commit, failure summary, and a direct link to the failed run.
The following checks currently have failure notifications wired:
Automated Triage Agent
On failure, check-engine workflows dispatch a Triage Agent (triage-agent.yml) that autonomously analyzes the failure and, when possible, proposes a fix:
- Fetches failed job logs from the GitHub Actions run
- Classifies the failure as infrastructure (transient) or code (actionable)
- Checks for existing triage work to avoid duplicate fix attempts
- Proposes a fix PR when the failure is code-caused — targeting the correct branch, respecting release-branch sync rules (cherry-pick to preserve
git patch-id) - Monitors CI on the fix PR until all checks pass
- Reports back to the Slack thread with classification, root cause, confidence level, and fix PR link
triage-security.md for Trivy failures) that provide domain-specific fix strategies — such as bumping dependency versions, regenerating lock files, or adding .trivyignore entries for unfixable CVEs.
Detailed Procedure: Secrets Detection
Service: GitGuardian Runs on: Every pull request (external integration, not a GitHub Actions workflow) GitGuardian scans every commit in every PR for leaked secrets including API keys, tokens, passwords, private keys, and cloud credentials. It runs as a GitHub check and blocks merge on detection.Detailed Procedure: Automated Code Review
Service: CodeRabbit (AI-powered) Runs on: Every pull request CodeRabbit performs automated code review on every PR, flagging potential security issues, bugs, and correctness problems. Its findings are advisory (do not block merge) but are triaged and addressed by the engineering team before merge.Dependency Update Monitoring
Service: GitHub Dependabot Coverage: Alerts enabled for known vulnerabilities in declared dependencies Dependabot monitors the repository’s dependency manifests and raises alerts when new vulnerabilities are disclosed. It also proposes automated PRs to upgrade vulnerable packages. As of this writing, Dependabot reports 25 known advisories against the default branch (15 high, 9 moderate, 1 low) — these are primarily OS-level packages excluded from the container scan scope and transitive dependencies with no direct fix available.GitHub Actions Security Hardening
The repository enforces a selected actions allow list at the repository level. Only explicitly approved third-party actions may be used in any workflow:
All GitHub-owned actions (
actions/*) are automatically permitted. Verified marketplace actions are not automatically permitted — they must be explicitly added.
This prevents supply-chain attacks via compromised or malicious third-party actions.