Overview
A GIS web platform had no systematic security scanning in its delivery pipeline — code, dependencies, and infrastructure definitions all shipped unscanned. The engagement added a CI/CD security stage covering SAST, SCA (dependency scanning), IaC scanning, and compiled-binary analysis — with the twist that it all had to run on self-hosted build agents with restricted network access, where cloud-connected scanner features simply don't work.
Offline Scanning & Reporting
The restricted agents forced a fully offline scanning setup: bundled policy sets with cloud downloads disabled, trading vendor-hosted guideline links for zero network dependency — a scanner that intermittently fails on a blocked endpoint is worse than one that never phones home. All scanners emit standard SARIF, surfaced directly in the CI platform's scan-results tab, so findings live where the team already works instead of a separate portal. The stage runs advisory (non-blocking) by design: findings inform prioritization without freezing delivery. Operational lessons baked in: scanner exit codes must be interpreted (findings are not tool failures), build outputs excluded from scans (duplicate findings, wasted minutes), and deprecated scanner components dropped rather than worked around.
Outcome
The platform went from zero systematic scanning to a repeatable, fully offline security stage on every build — SAST, dependency, IaC, and binary analysis reporting into the CI platform's native scan view, with a documented triage convention for new findings. Just as important is what the stage does NOT do: it doesn't block delivery on day one (advisory mode lets the team burn down the backlog at their own pace) and it doesn't depend on any external service staying reachable — the two properties that make a security stage survive contact with a real team's routine instead of being disabled the first week it inconveniences someone.