Security is eBPF's third domain, and arguably its most natural fit: the kernel sees every syscall, every process, every file access and network connection, so an eBPF program in the kernel is perfectly positioned to watch for and stop malicious behavior in real time. This is why modern runtime-security tools — detecting and blocking threats on live systems — are increasingly built on eBPF.
Security is eBPF's most natural fit: the kernel sees every syscall, process, file access, and network connection, so an eBPF program in the kernel is perfectly positioned to watch for and stop malicious behavior in real time. This is why modern runtime-security tools — detecting and blocking threats on live systems — are increasingly built on eBPF.
The CI/CD pipeline is one of the most privileged systems in an engineering organization — it has access to source code, secrets, and the keys to production — which makes it a prime target. Worse, it can become the delivery mechanism for an attack: compromise the pipeline and you compromise everything it ships. This post is about securing the pipeline itself and building security into it, the heart of DevSecOps.
The CI/CD pipeline is one of the most privileged systems in an org — access to source, secrets, and the keys to production — which makes it a prime target and a potential delivery mechanism for an attack. This post secures the pipeline itself (least privilege, secrets, pinned deps) and builds security into it (SAST/SCA/DAST), plus supply-chain integrity: SBOM, signing, SLSA provenance.
Individual controls — SBOMs, signing, provenance, dependency scanning — only add up to security when they're assembled into a coherent program with priorities, ownership, and a sensible starting point. This closing post turns the pieces into a practical roadmap: what to do first, how the controls reinforce each other, and how to build supply chain security incrementally without trying to boil the ocean.
Individual controls — SBOMs, signing, provenance, scanning — only add up to security when assembled into a coherent program with priorities, ownership, and a sensible starting point. This closing post turns the pieces into a practical roadmap: what to do first (dependency hygiene and SBOMs), how the controls reinforce each other, and how to build supply chain security incrementally without boiling the ocean.
The build system is where source becomes artifact — and where the most dangerous supply chain attacks strike, because tampering there produces a malicious release that looks completely legitimate. Securing the build means making it isolated, reproducible, and trustworthy enough that its provenance actually means something. This post covers hermetic builds, build isolation, and the practices that make "how it was built" a guarantee rather than a hope.
The build system is where source becomes artifact — and where the most dangerous supply chain attacks strike, because tampering there produces a malicious release that looks completely legitimate. Securing the build means making it isolated, reproducible, and trustworthy enough that its provenance actually means something. Hermetic builds, isolation, and platform-generated provenance.
Signing is how you turn "trust me, this artifact is authentic" into "verify it yourself." A cryptographic signature binds an artifact to its producer and proves it hasn't been tampered with since. But traditional signing has a painful key-management problem, and the modern answer — keyless signing with Sigstore — is what finally made artifact signing practical enough to be routine.
Signing turns 'trust me, this artifact is authentic' into 'verify it yourself.' A signature binds an artifact to its producer and proves it wasn't tampered with. But traditional signing has a painful key-management problem, and the modern answer — keyless signing with Sigstore — is what finally made artifact signing practical enough to be routine. Plus the verification half that makes signatures mean something.
An SBOM tells you what's in an artifact. Provenance tells you where it came from and how it was built — a tamper-evident record of the source, the builder, and the steps that produced it. It's the direct answer to the SolarWinds problem: a signed release means nothing if the build itself was compromised, so you need verifiable evidence of the build process, not just the output.
An SBOM tells you what's in an artifact; provenance tells you where it came from and how it was built — a tamper-evident record of the source, builder, and steps. It's the direct answer to the SolarWinds problem: a signed release means nothing if the build itself was compromised. This post covers provenance, attestation, in-toto, and the SLSA framework.
When the next Log4Shell-scale vulnerability is announced, the first question every organization must answer is "are we affected?" — and the teams that can answer it in minutes instead of weeks are the ones with an SBOM. A Software Bill of Materials is a complete, machine-readable inventory of everything in your software. It's the foundation of supply chain response, and increasingly, a requirement.
When the next Log4Shell-scale vulnerability is announced, the first question every organization must answer is 'are we affected?' — and the teams that can answer it in minutes instead of weeks are the ones with an SBOM. A Software Bill of Materials is a complete, machine-readable inventory of everything in your software: the foundation of supply chain response, and increasingly a requirement.
Most of your software is dependencies, so most of your risk is too. Dependency security is the practical, everyday discipline of controlling what you pull in, knowing when it's vulnerable, and updating without breaking — the highest-leverage supply chain work most teams can do. This post covers pinning, scanning, and the update discipline that keeps the dependency tree from becoming a liability.
Most of your software is dependencies, so most of your risk is too. Dependency security is the practical, everyday discipline of controlling what you pull in, knowing when it's vulnerable, and updating without breaking — the highest-leverage supply chain work most teams can do. Pinning, scanning, and the update discipline that keeps the dependency tree from becoming a liability.
To defend the supply chain you have to know how attackers get in — and there are more doors than most teams realize. Malicious packages, hijacked dependencies, dependency confusion, compromised build systems, and poisoned maintainer accounts each exploit a different link in the chain. This post is a field guide to the attack patterns, because each one maps to a specific defense.
To defend the supply chain you have to know how attackers get in — and there are more doors than most teams realize. Malicious packages, dependency confusion, compromised build systems, and poisoned maintainer accounts each exploit a different link. This post is a field guide to the attack patterns, because each one maps to a specific defense.
You don't just ship the code you wrote — you ship the code your dependencies wrote, and their dependencies, and the build system that assembled it all. That entire chain is your attack surface, and attackers have noticed. Software supply chain attacks target the trusted process by which software is built and delivered, and they've become one of the most damaging classes of breach precisely because they weaponize trust. This series is about defending that chain.
You don't just ship the code you wrote — you ship your dependencies' code, and the build system that assembled it all. That entire chain is your attack surface, and attackers have noticed. This opening post explains why supply chain attacks (SolarWinds, Log4Shell, registry attacks) became so damaging, and frames the defense: shift from implicit trust to explicit verification.
The question this phase answers is simple and unforgiving — can you change the system without breaking it? — and the control you cannot skip is that no ungated change reaches users.
Can you change the system without breaking it? Phase 6: automated pipelines for code, models, and prompts, with eval gates, a registry, and automated rollback — no ungated change reaches users.
The DevSecOps series finale — shifting right to runtime, turning compliance into code, closing the incident feedback loop, measuring what matters, and the culture that makes secure the default path.
The capstone: shifting right to continuous security — runtime detection and vulnerability management as a loop, security observability and tamper-evident audit, compliance-as-code with evidence from the pipeline, metrics that matter, and the culture (paved roads, champions).
The finale of the API Security series — how to bake security into the way APIs are designed, built, tested, shipped, and operated, so that every control from the previous seven posts becomes a repeatable part of the pipeline instead of a one-time heroic effort.
The capstone: baking security into the API lifecycle — shift-left threat modeling, CI gates (SAST, SCA, secret scanning, spec-driven authz/BOLA and DAST tests that fail the build), an OWASP-API-Top-10-to-control map, and incident response.
Securing the runtime platform end to end — hardened images, least-privilege workloads, default-deny networks, and admission control as the gate that decides what is ever allowed to run.
Securing the runtime platform: minimal non-root images scanned for CVEs, the container isolation model and hardening (drop caps, read-only FS, seccomp), and Kubernetes — Pod Security Standards, RBAC, default-deny NetworkPolicies, and admission control (Gatekeeper/Kyverno).
Part seven of the AI Security Engineering series: DevSecOps for AI systems — securing the secrets, network, supply chain, prompts, and CI/CD gates that surround the model, so a hardened model doesn't sit inside a soft pipeline.
DevSecOps for AI: secrets in a manager not code, least-privilege runtime identities (no ambient prod creds for agents), egress control, rate/spend limits against model DoS, supply-chain verification in CI, prompts-as-code, and a security-eval gate that fails the build.
Why your Terraform is a security control point, how misconfiguration scanners catch public buckets and open ingress before apply, and how to encode org guardrails as executable policy with OPA/Rego, Conftest, and Sentinel instead of a wiki page nobody reads.
Securing infrastructure definitions and enforcing guardrails automatically: IaC scanning (Checkov/tfsec/Trivy) for misconfig, drift detection, and policy-as-code with OPA/Rego + Conftest so org rules block bad infra before apply — not in a wiki.
How to move from hardcoded passwords toward dynamic, short-lived, audited credentials — the hierarchy from bad to good, the role of a real secrets manager, and why a leaked secret is compromised the instant you push it.
Keeping credentials out of code and under control: the bad-to-good hierarchy, secrets managers (Vault/KMS), dynamic short-lived secrets, rotation that consumers actually pick up, and workload identity / OIDC so CI and services never store a long-lived key.
Securing everything you didn't write — from finding known-vulnerable dependencies with SCA, to generating an SBOM you actually act on, to proving provenance with signatures and SLSA so you know and verify what you ship.
Securing everything you didn't write: SCA for known-vulnerable dependencies, the supply-chain threat model (typosquatting, dependency confusion, build compromise), SBOMs (SPDX/CycloneDX), and provenance/integrity with SLSA and Sigstore signing.
How the four families of automated security tests — static analysis, dynamic analysis, secret scanning, and instrumented runtime testing — fit together across a pipeline, and why tuning signal-to-noise matters more than adding scanners.
Automated security testing in the pipeline: SAST vs DAST vs IAST and their trade-offs, secret scanning (including git history), where each runs, and making findings actionable so false-positive fatigue doesn't get the scanner muted.
How to design security in from the first sketch instead of bolting it on before launch — mapping security work to every phase of the software lifecycle, grounded in the NIST Secure Software Development Framework, and using STRIDE-based threat modeling as the core design activity.
Designing security in from the start: the secure SDLC mapped to NIST SSDF, security requirements and abuse cases, and threat modeling with the four questions and STRIDE — data-flow diagrams, trust boundaries, and continuous (not one-time) modeling.
The opening post of a DevSecOps series — how security stops being a gate at the end of delivery and becomes an automated, shared responsibility built into every stage of the pipeline.
The opener to a DevSecOps series: building security into the delivery lifecycle instead of bolting it on — shift-left (and shift-right), security as everyone's job, the CI/CD pipeline as the enforcement point, and the automated controls the series wires up.