Cybersecurity That Fits The Delivery Pipeline
Practical controls that help teams ship safely without turning releases into archaeology.
Start With Delivery Reality, Not a Spreadsheet
Cybersecurity works best when it reflects how we actually build, test, deploy, and support software. A policy written for an imaginary perfect team will collect digital dust while engineers find ways around it. We’ve all seen it: a 40-page checklist arrives, nobody can explain the “why,” and suddenly every production change is labelled urgent. That’s not security; that’s paperwork with a siren.
Let’s begin by mapping the delivery path. We should know where code enters, where it is reviewed, where builds run, where artifacts live, how deployments are approved, and who can access production. This does not need a consulting engagement and a wall-sized diagram. A short workshop with engineering, operations, and security usually reveals the important bits quickly.
We should pay particular attention to trust boundaries. These are the points where code, credentials, data, or people move from one environment to another. For example:
- A developer workstation pushing code to Git
- A CI runner downloading third-party packages
- A deployment pipeline using cloud credentials
- An application reading customer data
- An on-call engineer accessing production during an incident
Each boundary deserves a sensible control. We don’t need to put a biometric scanner in front of a staging environment, but production credentials should not be sitting in a .env file beside someone’s lunch receipt.
A useful baseline is the NIST Secure Software Development Framework. It gives us a structured way to think about secure development without dictating every tool or process. We can translate its ideas into our own delivery language: protect repositories, review changes, validate builds, manage dependencies, and respond to weaknesses.
The goal is not “zero risk,” because that’s a fine slogan and a terrible plan. The goal is to reduce likely, high-impact failures while keeping delivery predictable.
Give Security Work Clear Owners And Deadlines
When everyone owns cybersecurity, nobody owns cybersecurity. It sounds harsh, but we’ve watched this film before. A vulnerability alert appears in a dashboard, several teams assume someone else is handling it, and six months later it is still waving at us from the backlog.
We need named ownership at every stage. Engineering teams should own the security of the services they build. Platform teams should own the safety and reliability of shared build and deployment systems. Security specialists should set standards, provide expertise, and help teams make risk decisions. Leadership should decide when a business deadline genuinely outweighs a security concern. That last part matters: teams should not be quietly forced to make business-risk calls from inside a pull request.
Ownership becomes useful when paired with expectations. We can classify findings by severity and exploitability, then set response targets that match reality. For example, an internet-facing critical vulnerability with known exploitation deserves immediate action. A low-risk issue in a development-only package may wait for normal maintenance work.
The CISA Known Exploited Vulnerabilities Catalog is especially helpful here. A vulnerability with active exploitation is not merely another red badge in a scanner. It should move toward the top of the queue, even if its generic severity score is less dramatic than another finding.
We should also make exceptions visible and temporary. If a team cannot patch immediately, document the reason, compensating controls, owner, and expiry date. An exception without an expiry date is not an exception; it is a feature request for future confusion.
Finally, let’s review open critical issues regularly with engineering and operational leaders. Fifteen focused minutes beats a monthly 90-minute meeting where everyone debates dashboard colours.
Put Guardrails Directly Into CI
The most dependable place to catch avoidable security mistakes is inside the pipeline. Developers are already working there, and feedback arrives while the change is still fresh. A finding discovered three weeks after release has had plenty of time to grow roots, make friends, and become expensive.
We should begin with a small set of checks that provide useful signal: secret detection, dependency scanning, static analysis for common flaws, infrastructure-as-code checks, and container image scanning where relevant. The important word is useful. If a check produces hundreds of noisy alerts, engineers will learn to ignore it with impressive speed.
Here is a simplified GitHub Actions example. It scans for leaked secrets, checks dependencies, and runs a container scan before an image is published.
name: security-checks
on:
pull_request:
push:
branches: [main]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Scan for secrets
uses: gitleaks/gitleaks-action@v2
- name: Check application dependencies
run: |
npm ci
npm audit --audit-level=high
- name: Scan container image
run: |
docker build -t registry.example.com/payments:${{ github.sha }} .
trivy image --severity HIGH,CRITICAL \
registry.example.com/payments:${{ github.sha }}
We should tune these checks in stages. Start in reporting mode, review the results, fix false positives, and identify recurring failure patterns. Then make high-confidence, high-severity findings block merges. We don’t need to make every informational warning a release stopper on day one. That approach creates bypasses faster than it creates safety.
Pipeline controls should also be versioned alongside the application or provided through approved reusable templates. Manual click-ops security settings are difficult to review, reproduce, or trust. If our pipeline is part of the production system—and it is—it deserves the same care as production code.
Treat Secrets Like Short-Lived Credentials
Long-lived secrets are a headache with excellent hiding skills. They end up in shell histories, CI variables, chat messages, backup files, and sometimes public repositories. Once exposed, we often cannot prove who copied them or where they travelled. Rotating them is cheaper than guessing.
Our first rule should be simple: no credentials in source control. That includes “temporary” test tokens, database passwords, private keys, and cloud access keys. If a secret lands in Git, removing it from the latest commit is not enough. Repository history, forks, logs, and caches may still contain it.
Instead, we should use a dedicated secrets manager and retrieve credentials at runtime or during a tightly controlled deployment step. Better still, use workload identity or OpenID Connect federation so CI systems can receive short-lived cloud credentials without storing a permanent key.
A deployment configuration might look like this:
deploy:
environment: production
identity:
provider: oidc
audience: cloud-deployer
secrets:
database_url:
source: vault
path: production/payments/database_url
stripe_api_key:
source: vault
path: production/payments/stripe_api_key
permissions:
- deploy:payments-api
- read:production-config
The deployment process receives only the permissions it needs, for only as long as it needs them. That is much safer than giving every pipeline a broad cloud administrator key and hoping nobody gets curious on a Friday afternoon.
We should also rotate credentials routinely, especially for third-party services and emergency “break glass” accounts. Logging every secret access gives us an audit trail and helps during incident response. It is not glamorous work, but neither is replacing every cloud credential at 2 a.m. because a token appeared in a paste site.
Secure The Dependencies We Did Not Write
Most software is assembled from components we did not write: open-source libraries, base images, build plugins, operating system packages, and hosted services. That is normal and useful. It also means our cybersecurity posture depends partly on code maintained by people we may never meet and packages named almost exactly like the ones we intended to install. Typosquatting is a surprisingly cheap attack; apparently one missing letter can be very profitable.
We should create and maintain a software bill of materials, or SBOM, for each production release. An SBOM helps us answer the question that matters during a new vulnerability announcement: “Are we affected?” Without it, teams often begin an unpleasant repository treasure hunt.
Package versions should be pinned where practical, and lock files should be committed. We should use trusted registries, review new dependencies, and avoid pulling arbitrary scripts directly from the internet during a build. Base container images deserve the same attention. A tiny official image is usually preferable to a mystery image with 14 million pulls and a description reading, “works great!!!”
Supply-chain provenance is increasingly important. The SLSA framework offers practical guidance for improving build integrity, while Sigstore provides tools for signing and verifying artifacts. We do not need to adopt every level immediately, but signing release artifacts and verifying them before deployment is a strong early step.
Dependencies also need maintenance owners. Automated update pull requests can help, but they are not magic. Someone must review, test, and merge them. We should schedule regular dependency maintenance rather than waiting for a critical advisory to turn routine upkeep into a fire drill.
Limit Production Access And Watch What Matters
Production is where cybersecurity mistakes become business problems. That means access should be deliberate, limited, and observable. We should avoid shared administrator accounts, permanent broad permissions, and “just give them production access for now” arrangements. “For now” has an astonishingly long shelf life.
Role-based access control is a reasonable starting point. Developers may need logs and metrics for their services, while only a smaller group needs permission to change infrastructure or modify customer data. Sensitive actions—such as changing identity policies, disabling logging, or exporting large datasets—should require stronger approval and generate alerts.
Just-in-time access is particularly helpful. Instead of assigning standing production privileges, we can grant elevated access for a short, approved period. This reduces the number of permanently powerful accounts and gives us a cleaner audit trail. During an incident, we still need a break-glass process, but it should be monitored, documented, and tested before the real emergency arrives.
Logging matters, but we should not drown in it. We need reliable records for authentication events, privilege changes, deployment activity, access to sensitive data, and unusual network or API behaviour. Centralize these logs, protect them from modification, and define retention periods that meet operational and legal needs.
Alerts should focus on events someone can act on. A notification for a new production administrator is useful. A notification every time a healthy service handles a normal request is an electronic mosquito. Alert fatigue is not a character flaw; it is the predictable result of noisy systems.
Regular access reviews close the loop. If someone changed roles, left the company, or no longer supports a service, their permissions should change too. Boring? Yes. Important? Also yes.
Measure Progress And Rehearse The Bad Days
We cannot improve cybersecurity with vague statements such as “security is important.” Everyone agrees with that, including the person who just approved a public storage bucket for a one-off test. We need a few measurements that show whether our controls are working and where delivery risk is accumulating.
Useful measures include the percentage of repositories with protected branches, multi-factor authentication coverage, critical vulnerability remediation time, percentage of production artifacts with an SBOM, secret rotation compliance, and the number of services using short-lived deployment credentials. We should also track exceptions: how many are open, who owns them, and how many have expired.
Metrics should guide conversations, not become weapons. If one team has slower remediation times, we should investigate whether they lack staff, test coverage, upgrade automation, or platform support. Punishing teams for reporting problems simply teaches them to report fewer problems. That may improve a chart, but it does not improve security. Charts are easily frightened creatures.
We should also practise incident response. A tabletop exercise every few months is enough to reveal gaps in contacts, decision-making, access, communications, and backups. Pick a realistic scenario: a leaked deployment token, compromised dependency, ransomware in a shared environment, or suspicious production data access. Ask who detects it, who can disable access, who informs customers, and how we restore service.
After each exercise or real incident, write down improvements and assign owners. The point is not to perform a flawless drill. The point is to make the first real incident less chaotic than it would otherwise be.
Good cybersecurity is steady operational work: clear ownership, sensible controls, reliable automation, and regular practice. No capes required—though a decent incident coffee supply never hurts.
