In short
Three of our open-source command-line tools now ship a GitHub Action, listed on the GitHub Marketplace: site-audit checks a web page, port-audit checks the app running on a port in your job, and agent-config-audit checks what an AI coding agent will load or run in your repository. Each one is a single step that scans once, prints the report in the log and the job summary, exposes the finding counts as outputs and, by default, fails the job when anything is in "Fix now".
Key points
- One line adds each check to a workflow:
uses: BYDTechSolutions/site-audit@v0,BYDTechSolutions/port-audit@v0orBYDTechSolutions/agent-config-audit@v0. - Every Action prints its report in the log and the job summary and fails the job on "Fix now" unless you set
fail-ontoshould-fixornone. - port-audit and agent-config-audit write SARIF, which GitHub can show as code-scanning alerts; site-audit can write its self-contained HTML report.
- site-audit’s speed results and Google’s Lighthouse scores need a PageSpeed Insights API key.
- Each tool states what it does not check. An empty report means no findings for those checks, nothing more.
What shipped
We published GitHub Actions for three of our open-source packages. Each Action runs the same npm package as the command-line tool, so a report from CI reads the same as one from your terminal. @v0 follows each 0.x release; pin the full version to stay on one.
| Package | Workflow step | Version to pin | What it checks |
|---|---|---|---|
| site-audit | uses: BYDTechSolutions/site-audit@v0 | @v0.1.5 | One web page: SEO, AI-crawler access, structured data, link previews, speed, accessibility, security headers, installed tags and broken links |
| port-audit | uses: BYDTechSolutions/port-audit@v0 | @v0.1.3 | The app running on a port in your job: headers and CSP, cookie flags, CORS, TLS, TRACE, scripts without integrity hashes, known-vulnerable front-end libraries and version headers |
| agent-config-audit | uses: BYDTechSolutions/agent-config-audit@v0 | @v0.1.2 | The agent config in your repository: hooks, MCP servers, skills, plugins, rules files and env overrides |
Each package page has the full workflow file and every input. The Marketplace listings are linked in the sources below.
What every Action does
- It scans once and prints the report in the job log.
- It adds the same report to the job summary, which GitHub shows on the workflow run’s summary page.
- It fails the job when any finding is in "Fix now". The
fail-oninput moves that line to "Should fix" or turns it off withnone. - It exposes the finding counts as step outputs (
fix-now,should-fix, andnice-to-haveor, for agent-config-audit,review), plus the paths of the JSON and Markdown reports, so a later step can act on them. - port-audit and agent-config-audit also write a SARIF file. site-audit writes its self-contained HTML report when you set
html-file, and itsscoresoutput holds Google’s Lighthouse scores as JSON when PageSpeed Insights ran. - port-audit and agent-config-audit take a
baseline: an earlier JSON or SARIF report whose findings are hidden, so the job fails only on new ones. - They need Node.js 20 or later on the runner, which GitHub-hosted runners have, and run on Linux, macOS and Windows runners.
One change reaches the command-line tools too: --out can now be repeated in all three, so one run writes several formats, for example npx @bydtech/port-audit --port 3000 --out report.json --out report.sarif.
What each one checks, and what it does not
site-audit audits one URL: a staging or preview address, or your app started on localhost in an earlier step. It reads the HTML the server sends and runs no JavaScript, and it does not crawl the whole site. Its speed results and Google’s Lighthouse scores come from the PageSpeed Insights API, so pass a key with the psi-key input; without one they are usually missing, and args: --no-psi skips them on purpose.
port-audit is passive: it reads pages with GET, OPTIONS and TRACE requests and, for https, makes two TLS handshakes, and it submits no forms and injects nothing. It scans only localhost and private networks unless you name a host you own with the i-own-this input. It does not look for exposed files or endpoints, directory listings, error leakage or open redirects, and it does not test injection, sign-in, sessions or access control. Each finding carries its OWASP Top 10:2025 and ASVS 5.0 references and a fix for the framework it detects.
agent-config-audit reads the files that Claude Code, Cursor, GitHub Copilot, Gemini CLI, Codex and other agents load, and flags risks against the OWASP Agentic Skills Top 10. It works offline and never runs, installs or fetches anything it finds. With command: diff the step fails when the config has changed since your committed agent-config.lock. It is not a malware check: an attack written to avoid its rules gets through.
None of the three replaces a review by a person. For the wider picture, see our web app security checklist and technical SEO checklist.
Findings as code-scanning alerts
GitHub can show a third-party tool’s SARIF file as code-scanning alerts. Its documentation describes the route: give the workflow the security-events: write permission and add a step with GitHub’s upload-sarif action, pointing at the file the audit wrote (port-audit.sarif or agent-config-audit.sarif by default). On private and internal repositories, GitHub says code scanning needs GitHub Code Security to be enabled.
A port scan never sees your source code, so port-audit files each alert under a made-up path such as port-audit/localhost/index and names the URL in the message. agent-config-audit points at the real file and line.
Getting started
- Pick the check that fits the job: a page you can reach by URL, an app you can start in the job, or a repository where AI agents work.
- Copy the example workflow from the package page: site-audit, port-audit or agent-config-audit.
- Run it once with
fail-on: noneto see what it finds, then fix those findings or save the report as abaseline. - Set
fail-onback tofix-nowso new problems stop the build.
All three are MIT-licensed. Issues and pull requests are welcome in each repository, and the rest of our packages are on the open source page.
Sources
Checked when this post was written.