Before images from the tax-portal pipeline can deploy, the workflow runs container image scanning and secret detection. Why include those steps?
Select an answer to reveal the explanation.
Short Explanation
Image scanning and secret sniffing are the security checkpoint in the pipeline—catch the CVEs and the accidental API keys before production. Shifting that left beats finding a leaked key in a public registry later. Pretty PDFs and marketing timers aren’t the point.
Full Explanation
Before images from the tax-portal pipeline can deploy, running container image scanning and secret detection includes security stages that catch vulnerable packages and leaked credentials early. Shifting those checks left reduces the chance that known CVEs or embedded keys reach municipal production where citizen tax data flows. Those stages are not merely graphic-design accessibility checklists for PDFs. Their purpose is not to increase page-load metrics used by marketing analytics. They do not replace the need for an identity provider in the cloud tenant—IdP controls authentication while pipeline scanning addresses supply-chain and secret hygiene. Exam caveat: define severity-based fail policies; blocking critical Internet-facing findings for a tax portal is expected civic practice, while medium findings may be tracked with deadlines rather than ignored. Operational check: enable image CVE and secret scanning on the tax-portal pipeline, fail builds on policy violations, verify a planted test secret is caught in a non-prod branch, remediate real findings before deploy, and retain scan reports for municipal audit evidence. In municipal cloud operations, record the chosen control and the rejected alternatives in the change or incident ticket so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same decision still holds under current provider limits, identity bindings, and application versions used by the civic platform team.