Sec Security Vulnerability Analysis

Optional inputs

• lockfiles
• Docker or container context
• IaC files
• guidelines

Outputs

• vulnerability analysis report
• secret scanning report
• remediation recommendations
• CI/CD scanning recommendations

Workflow phase and review mode

• Workflow phase: implementation, pull-request review, release readiness
• Review mode: human review for high or critical findings, leaked secrets, production-impacting scanner failures, or risk acceptance

Operating pattern

• Scan by surface: dependencies, secrets, filesystem/container, IaC, and workflow definitions.
• Prefer GitHub-native PR and repository protections where available, then supplement with local or CI tools for broader coverage.
• Separate exploit-ready findings from hygiene issues or informational notices.
• Convert findings into remediation work, not just raw scanner output.

Guideline lookup

• Follow docs/guidelines/shared-operating-policy.md#guideline-lookup.

Story and artifact maintenance

• Follow docs/guidelines/shared-operating-policy.md#story-maintenance for backlog, evidence, and follow-up updates tied to this skill.

Quality bars

• Secret findings are treated as urgent until proven false or revoked.
• High and critical dependency or container findings must be triaged explicitly.
• Ignore lists, suppression files, and policy exceptions need an owner and rationale.

Failure modes to avoid

• Treating every CVE equally without considering exploitability, exposure, or fix availability.
• Depending only on one scanner category.
• Leaving leaked secrets unrotated after detection.
• Failing to scan containers or IaC when the repository clearly ships them.

Completion checklist

• Use docs/guidelines/shared-operating-policy.md#completion-checklist as the default completion gate for this skill.

Detailed workflow

1. Inventory lockfiles, manifests, package managers, Dockerfiles, container images, Terraform/Kubernetes assets, and workflow files.
2. For pull requests, prefer GitHub dependency review so new vulnerable dependencies are flagged before merge.
3. For dependency vulnerability scanning, use OSV-based or ecosystem-native tooling such as OSV-Scanner, pip-audit, or package-manager audit commands when they are appropriate to the detected stack.
4. For secrets, use Gitleaks locally or in CI and enable GitHub secret scanning or push protection when the repository tier supports itsecrets, and license issues in build or deployment assets. Generate SBOM (CycloneDX/SPDX) for transparency.
5. Triage findings: For each CVE/finding, answer (1) Is it reachable in production code? (2) Is it exploitable in your context? (3) Is a patch available? (See cve-triage-guide.md for decision framework.) Categorize as Confirmed Issue, Hotspot, False Positive, or Accepted Risk. For secrets, treat as urgent: rotate/revoke immediately, scan git history, and notify stakeholders. Create prioritized remediation storint assets.
6. Triage findings by severity, reachability, exposure, and fix path. Create remediation work, revoke or rotate exposed secrets, and rerun the relevant scans after fixes.
7. Use the workflow scaffold helper in this package when the project needs repository-native GitHub scanning baselines.

Dependency Scanning

• GitHub dependency review can fail pull requests that introduce vulnerable dependencies and works best when dependency submission data is consistent for the target branch.
• OSV-Scanner is useful for multi-ecosystem dependency vulnerability checks and has reusable GitHub workflows.

Secret Scanning

• GitHub secret scanning plus push protection is the strongest default when available because it can stop secret exposure before the push lands.
• Gitleaks is a practical local and CI secret scanner for repositories and filesystem paths.

Example: Python service with Dockerfile

Scan:

• Run dependency review on PRs, pip-audit -r requirements.txt, osv-scanner scan source -r ., gitleaks dir ., and trivy fs . --format json for structured results.

Triage Example:

• Found: CVE-2025-1000 (High) in requests library, v2.28.0.

• Q1: Reachable? Yes (direct dependency, used in main service).

• Q2: Exploitable? Yes (HTTP request input is user-controlled).

• Q3: Patch available? Yes (v2.31.0 has fix).

• Decision: P1. Create blocking story: "Upgrade requests to v2.31.0". Block release.

• Found: Dev-only: CVE-2025-2000 (Medium) in pytest-mock.

• Q1: Reachable in production? No (test-only).

• Decision: P3. Add to suppression record with reason "dev-only", review in 90 days.

Example: TypeScript app with Kubernetes manifests

Scan:

• Run dependency review, OSV or npm audit, gitleaks, and trivy fs . to cover lockfiles, manifests, Docker assets, and secret patterns.
• Generate SBOM: syft . -o spdx-json > sbom.spdx.json.

Secret Handling Example:

• Gitleaks found: Exposed AWS_SECRET_ACCESS_KEY in terraform/prod.tf.
• Immediate action: Rotate key in AWS console, update Secrets Manager.
• Scan history: git log -p -- terraform/prod.tf | grep -i secret (check for exposure timeline).
• Notify: Alert infra team and AWS audit; document response in security log.
• Remediation: Create story "Remove exposed secret from git history" (git filter-branch or similar).

Example severity handling & triage categories

See report.template.md for structured report format and cve-triage-guide.md for detailed decision framework

• Generate SBOM (CycloneDX or SPDX format) as part of vulnerability analysis. Use tools like syft or Trivy's SBOM output.
• Include SBOM in compliance reports and transparency documentation.

Triage Framework

• Map findings to decision matrix: Severity × Reachability → Action (Fix Now / Plan / Backlog).
• Document false positives and suppressed findings with reason, owner, and review date.
• Use report.template.md to structure output and ensure consistent triage categori
• Trivy can scan filesystem trees, repositories, containers, and IaC for vulnerabilities, misconfigurations, secrets, and license issues.

Examples

Example: Python service with Dockerfile

• Run dependency review on PRs, pip-audit -r requirements.txt, osv-scanner scan source -r ., gitleaks dir ., and trivy fs ..
• If a high CVE exists only in a dev-only package, record the context; if it affects the runtime image or production path, create a blocking remediation story.

Example: TypeScript app with Kubernetes manifests

• Run dependency review, OSV or npm audit, gitleaks, and trivy fs . to cover lockfiles, manifests, Docker assets, and secret patterns.
• If the scanner finds an exposed token in a workflow or manifest, rotate the secret, remove it from history if needed, and document the response.

Example severity handling

• Critical/high: block release until fixed or explicitly accepted by a human owner.
• Medium: remediate in the current sprint or create a dated follow-up story with context.
• Low/info: tune or backlog only if the issue is real and worth tracking.

Local assets

• run_vulnerability_analysis.py
• scaffold_security_workflows.py
• report.template.md

Integration with implementation execution

This skill is part of the automatic implementation feedback loop. Treat dependency, secret, container, and IaC findings as implementation feedback that should be triaged and, when safe, repaired immediately.