Run API security checks in GitHub Actions on staging

Run the check against an already deployed, authorized staging target from a trusted ref. Tie the result to that build’s revision. Pass the token through a protected environment and preserve the CLI exit status so a partial run cannot turn green.

Scantelio editorial team · 2026-11-05

What to prepare

Use a project with CI access, verified ownership and scan consent. Save the workflow in .github/workflows/ and reviewed copies of scantelio.mjs and run-ci.sh in ci/. Pin the reviewed file versions in your repository.

Verification procedure

Bind credentials and settings to staging

Create a protected staging environment. Set SCANTELIO_API_URL, SCANTELIO_PROJECT, SCANTELIO_ENVIRONMENT and SCANTELIO_DEPLOYMENT as variables and SCANTELIO_TOKEN as a secret. Restrict the refs that may use that environment.

Check the selected revision before dispatch

Select a trusted branch or tag for workflow_dispatch. Compare github.sha with the build actually deployed; deploy the correct revision first if they differ. Never expose the token to untrusted pull-request code or enable shell tracing.

Decide what happens next from the process exit code

0 → the configured gate passed
1 → blocking finding: hand the evidence to a developer
2 → error or incomplete coverage: repair the inputs and rerun

Decision and limitations

Keep findings and incomplete results distinguishable in logs. Both should fail the job; do not mask them with continue-on-error. Configure required checks or deployment protection separately if this is a release condition.

What remains unverified

This manually dispatched workflow does not run on every pull request. A passing gate covers its configured checks. Cancelling the job may leave a server-side run active.