Your CI YAML. Replace the demo seed, or mount your .github/workflows.
How It Works
Two scanners read the pipelines: one for CI/CD misconfig, one for coding-agent jobs. Findings are merged.
Results
Pipeline and coding-agent findings, plus report.json.
Overview
Pipeline YAML is attack surface. Unpinned Actions, pull_request_target on untrusted code, secret-rich runners, and coding-agent jobs with yolo or secret handoff are the patterns that turn a workflow file into a poisonable path. Tag-poisoning and mass Actions injection kept that floor loud through 2025-2026. Operators need a repeatable inventory of that surface on their repos, plus a diff when configs change.
This is a standing check for continuous security testing. You feed GitHub Actions YAML, run BHUSA 2026 Arsenal Trajan for pipeline misconfig alongside a coding-agent CI scan, and get correlated findings you can schedule as a retest delta when workflows change.
It sits next to the library GitHub Secret Scanner (history secrets, not workflow trust). This Collection unit is the offline CI YAML path: demo fixtures seed by default; swap in your cloned .github/workflows with no vault token on the graph.
Pipeline
seed-ci-yaml emits small demo GitHub Actions YAML (including pull_request_target and a yolo-style agent step).
Trajan scans that path with platform defaulting to github (offline path scan; token and target stay unset).
Coding-Agent CI Scan reads the same seed folder for agent-in-CI trust patterns.
correlate merges both folders into inventory, findings, summary, and retest_delta outputs.
Inputs
Seed CI YAML folder. Default demo fixtures. Replace the seed output or point Trajan path and ci-scan input at your YAML tree (flat or under .github/workflows/).
Trajan platform. Default github. Other Trajan platforms exist on the tool; the fixture path exercises GitHub Actions.
Trajan token / target. Leave unset for a local YAML scan. Set target plus a Vault token (BH_GITHUB_TOKEN is already wired) for API mode against owner/repo or an org.
ci-scan repo label. Default fixture/demo for the seed path.
Outputs
findings.jsonl. Priority CI/CD misconfig and coding-agent trust-boundary hits.
inventory.jsonl. Repos and paths observed in the run.
summary.jsonl. Rollup for the correlate pass.
retest_delta.jsonl. Schedule-as-diff scaffold when you re-run after workflow changes.
Integrations
Trajan (BHUSA 2026 Arsenal; private vault tool)
Coding-Agent CI Scan (private vault tool)
Sample output
Sample shape from the correlate pack on demo fixtures (illustrative, not a live KPI).
source
severity
title
path
repo
kind
note
trajan
high
Unpinned or poisonable Actions pattern
.github/workflows/demo.yml
null
null
null
ci-scan
critical
Coding-agent yolo / secret-handoff pattern
null
fixture/demo
null
null
null
null
null
null
null
retest_delta
Schedule re-runs to diff findings when workflow YAML changes
FAQ
Does the default run scan my GitHub org?
No. The default seed is demo YAML on the canvas. Bring your own workflow files via the sticky on the left, or set Trajan target plus a token for API mode.
Do I need a GitHub token?
Not for a local YAML scan. Point Trajan and the coding-agent scan at a folder of workflow files. Token plus target is the API path; the Vault chip is already on Trajan token.
How is this different from GitHub Secret Scanner?
That workflow hunts credentials in git history with TruffleHog. This Collection unit inventories pipeline and coding-agent trust risks in Actions YAML via Trajan and the coding-agent CI scan.
Why schedule this?
Correlate emits retest_delta.jsonl so a scheduled re-run can surface posture change when workflows land. Weekly or after CI template changes is a sensible floor for active orgs.
Does Trajan cover GitLab and Azure DevOps here?
Trajan can target more than GitHub. The Collection default and fixture path are GitHub Actions only. Treat other platforms as capabilities you configure deliberately, not as proven by the seed run.
Related workflows
GitHub Secret Scanner. Reach for this instead when you need leaked keys in commit history, not workflow trust boundaries.
Multi-Cloud Dangling DNS. Reach for this instead when the job is cloud DNS takeover risk, not CI YAML.