Overview
Kayston’s Forge implements multiple layers of automated security scanning to detect and remediate vulnerabilities in dependencies. The application uses npm audit, GitHub CodeQL, Dependabot, TruffleHog secret scanning, and SBOM generation to maintain supply chain security.All security scans run automatically on every push and pull request. Critical findings block merges until resolved.
CI/CD Security Pipeline
The security pipeline is defined in.github/workflows/security.yml and runs on:
- Every push to
mainbranch - Every pull request
- Weekly scheduled scans (Mondays at 08:00 UTC)
- Manual workflow dispatch
npm audit
Configuration
Dependency auditing runs on every build with critical-only failure threshold:Why HIGH Advisories Don’t Apply
Next.js 14 has two known HIGH severity advisories:- GHSA-9g9p: React Server Components deserialization vulnerability
- GHSA-h25m: Image Optimization API SSRF vulnerability
output: 'export':
- No server runtime exists
- No React Server Components
- No Image Optimization API
- No API routes or middleware
- Pure static HTML, CSS, and JavaScript
This is documented in
CLAUDE.md:88 and security.yml:27-31. The advisory exclusion is architecture-validated, not ignored.Running npm audit Locally
Audit Workflow
When npm audit detects vulnerabilities:- CRITICAL: CI fails immediately, blocks all merges
- HIGH: Reviewed manually, excluded if not applicable to static export
- MODERATE/LOW: Tracked in issues, fixed in weekly dependency updates
GitHub CodeQL (SAST)
Configuration
CodeQL performs static application security testing (SAST) on all TypeScript/JavaScript code:Query Suite: security-extended
Thesecurity-extended query suite includes:
- CWE Coverage: 150+ security-relevant code patterns
- Common Vulnerabilities: XSS, SQL injection, path traversal, etc.
- JavaScript/TypeScript Specific: Prototype pollution, unsafe regex, eval usage
- Framework Patterns: React-specific security issues
CodeQL results are visible in the Security → Code scanning alerts tab of the GitHub repository.
Example Detections
CodeQL catches issues like:False Positive Handling
If CodeQL flags a false positive:-
Add a comment explaining why it’s safe:
- Dismiss the alert in GitHub Security tab with justification
- Document architectural mitigations (e.g., sandboxed iframes)
TruffleHog Secret Scanning
Configuration
TruffleHog scans for leaked secrets (API keys, passwords, tokens) in git history:Two-Pass Scanning
-
Verified Secrets (blocks CI):
- API keys that TruffleHog confirms are valid via test requests
- AWS credentials, GitHub tokens, Stripe keys, etc.
- Action: Build fails immediately
-
Unverified High-Confidence (warning only):
- Pattern matches that look like secrets but aren’t verified
- Potential false positives
- Action: Warning logged, doesn’t block build
Common False Positives
Excluded Patterns
TruffleHog automatically excludes:- Package lock files (
package-lock.json) - Dependency directories (
node_modules/) - Build outputs (
out/,.next/) - Test fixtures with intentionally fake secrets
Dependabot
Configuration
Dependabot automatically opens pull requests for dependency updates:Update Strategy
| Update Type | Behavior | Rationale |
|---|---|---|
| CRITICAL security fix | Opens individual PR immediately | Urgent, must review and merge ASAP |
| Minor/patch updates | Grouped into single weekly PR | Reduces PR noise, easier to review batch |
| Major version bumps | Ignored by Dependabot | Breaking changes require manual review |
| GitHub Actions | Grouped into single weekly PR | Lower risk, batch updates |
Dependabot PRs automatically trigger the full security pipeline (npm audit, CodeQL, TruffleHog, SBOM generation) before merge.
Reviewing Dependabot PRs
When reviewing dependency update PRs:- Check CI Results: All security checks must pass (green checkmarks)
- Review Changelog: Click through to dependency’s release notes/changelog
- Test Locally: Pull branch and run
npm run build && npm run test - Check Bundle Size: Verify no unexpected size increases (use
npm run analyzeif available) - Merge Strategy: Squash-merge to keep main branch history clean
Ignoring False Positive Alerts
If Dependabot opens a security PR for a non-applicable vulnerability:.github/dependabot.yml:
SBOM Generation
Configuration
Software Bill of Materials (SBOM) is generated automatically on every release:SBOM Format: CycloneDX
The SBOM is generated in CycloneDX 1.5 JSON format, which includes:- Component Inventory: All npm dependencies (direct and transitive)
- Version Information: Exact versions from
package-lock.json - License Data: SPDX license identifiers
- Dependency Graph: Parent-child relationships
- Hashes: SHA-512 checksums for verification
- Vulnerability Data: Known CVEs (if available)
CycloneDX is one of two industry-standard SBOM formats (the other is SPDX). It’s optimized for security use cases and vulnerability tracking.
Example SBOM Structure
Accessing SBOMs
- GitHub Releases: Download
sbom.jsonfrom any release page - GitHub Actions Artifacts: Download from workflow runs (90-day retention)
- Generate Locally:
SBOM Use Cases
| Use Case | Description |
|---|---|
| Vulnerability Tracking | Cross-reference against CISA KEV catalog |
| License Compliance | Audit all transitive dependency licenses |
| Supply Chain Security | Detect malicious package injections |
| Incident Response | Quickly determine if vulnerable package is in use |
| Procurement | Provide to customers for their security audits |
SBOMs are increasingly required for federal procurement (NIST SSDF, EO 14028) and enterprise security questionnaires.
SBOM Vulnerability Analysis
To check SBOM against known vulnerabilities:Vulnerability Management Process
Severity Levels
| Severity | SLA | Action |
|---|---|---|
| CRITICAL | 24 hours | Hotfix branch, emergency release |
| HIGH | 7 days | Scheduled patch release |
| MODERATE | 30 days | Bundled into next minor release |
| LOW | 90 days | Tracked in backlog |
Vulnerability Response Workflow
- Detection: Automated alert from npm audit, Dependabot, or CodeQL
- Triage: Security team reviews within 24 hours
- Assessment: Determine applicability to static export architecture
- Remediation:
- Patch available: Dependabot PR → review → merge
- No patch: Evaluate workarounds or dependency replacement
- Not applicable: Document rationale, dismiss alert
- Verification: Re-run security pipeline after fix
- Disclosure: Update security advisories if user-facing
Tracking Known Vulnerabilities
Current known issues (as of documentation date):| Dependency | Advisory | Severity | Status | Rationale |
|---|---|---|---|---|
[email protected] | GHSA-9g9p | HIGH | Dismissed | RSC feature not used in static export |
[email protected] | GHSA-h25m | HIGH | Dismissed | Image Optimizer disabled (unoptimized: true) |
This table is maintained in
docs/SECURITY.md and reviewed quarterly.Supply Chain Security Best Practices
Lessons learned from this implementation:1. Lockfile Discipline
Always commitpackage-lock.json:
2. Minimize Dependencies
Every dependency is a potential vulnerability:- Audit new dependencies before adding (
npm audit, check GitHub stars/maintenance) - Prefer stdlib or built-in browser APIs over packages
- Regularly review
package.jsonfor unused dependencies
3. Pin GitHub Actions
Use commit SHAs, not tags:4. Review Transitive Dependencies
Most vulnerabilities are in transitive (indirect) dependencies:5. Automated vs. Manual Updates
| Update Type | Strategy |
|---|---|
| Security patches | Automated (Dependabot) |
| Minor/patch updates | Automated (Dependabot) |
| Major version bumps | Manual review + testing |
| Breaking changes | Manual migration + documentation |
Integration with Other Security Measures
Dependency security is one layer of defense-in-depth:Runtime Security
- CSP: Blocks malicious scripts even if dependency is compromised
- Subresource Integrity (SRI): Planned for CDN assets
Development Security
- Pre-commit hooks: Run
npm auditbefore allowing commits - PR templates: Checklist includes “dependencies reviewed”
Incident Response
- SBOM availability: Rapid vulnerability assessment during incidents
- Rollback plan: Previous releases remain available with SBOMs
Continuous Improvement
Future enhancements under consideration:1. SBOM Vulnerability Monitoring
Automate SBOM uploads to vulnerability tracking platforms:- OWASP Dependency-Track
- GitHub Dependency Graph
- Snyk/Sonatype/JFrog Xray
2. Reproducible Builds
Generate and verify build provenance:3. License Compliance Automation
Automate license auditing:4. Dependency Review Action
Add GitHub’s dependency review action to PRs:Conclusion
Kayston’s Forge implements a comprehensive dependency security program combining:- Automated scanning: npm audit, CodeQL, TruffleHog
- Continuous monitoring: Dependabot weekly updates
- Supply chain transparency: CycloneDX SBOM generation
- Documented exceptions: Architecture-validated advisory dismissals
All security tooling is configured in version control (
.github/workflows/) and runs automatically. No manual intervention is required for routine scans.