Automation vs Human Judgment in Cybersecurity Containment

Your CI pipeline is not less risky than production. It runs with secrets, has internet access, and most engineers treat it as config, not code. Wiz published a full GitHub Actions threat model this week. A few things that stood out: → Untrusted inputs in `run:` steps can trigger script injection without a single PR approval → `GITHUB_TOKEN` is routinely over-permissioned and scoped to the whole repo → Third-party actions are supply chain risk by default. Pinning to a SHA is not optional. → Secrets in env vars leak into logs more often than most teams realize Full breakdown in the comments ↓ #devops #security #githubactions

Anthropic unintentionally exposed over 500,000 lines of Claude Code, shipped inside their own npm package. Yes you heard it right, 500,000 lines of Claude Code. It wasn’t a breach. It was a release. A routine update included a 60MB debug artifact that should never have been there. Inside it: a significant portion of their internal codebase. Within hours: • Thousands of forks appeared across GitHub • The code spread faster than it could be contained • Takedown requests followed, but the damage was already done. This wasn’t the result of a sophisticated attack. It came down to something far more common and far more dangerous: • A missing exclusion rule in the package configuration. • A manual deployment step where automation should have existed. The kind of oversight most teams assume “won’t happen to us.” Boris Cherny, who led Claude Code’s growth into a multi-billion dollar product, addressed it directly: “The system failed, not the person.” No deflection. No noise. Just accountability and a focus on fixing the process. Because at scale, it’s rarely a single mistake that breaks things. It’s the absence of safeguards that were supposed to catch it. #softwareengineering #devops #security #buildinpublic #claudecode

Claude Code is not ONLY for programmers... I have used it to do DevOps type of things fixing vulnerabilities... and tonight I pushed it to do more, and it did surprisingly well... I don't think I would be able to accomplish below in one night without agents: - create a podman machine and a kind k8s cluster. - (this step is relatively straightforward) - install and config cert-manager operator to provide TLS - a more realistic production-grade lab environment - install and config Prometheus, Grafana stack - install and config cockroachDB, the PostgreSQL on steroid - the DB that won't die  - access all these from local laptop to these resources running in a k8s cluster within the laptop - automated the lab shutdown and restart - tested working! - capture all the learning into documentation - there were quite some gotchas could easily put me up for many whole-nighters. - create a skill so that Claude Code could help me to recreate the whole lab automatically, or perform some tasks, or troubleshooting if needed, in the future wow, amazing agents could really amplify every one of us and make the impossible possible, if you give them a chance...   CHEERS #claudecode #podman #kind #k8s #cockroachdb

Continuing my work on SysGuard - this week I focused on something less visible than system checks, but much more critical in real environments: secrets handling. I've just completed the Configuration & Secrets Hygiene block from my roadmap. What was implemented: 🔸 Secret masking in reports and logs Sensitive values are now automatically redacted: based on key names (password, token, api_key, etc.) based on inline patterns (e.g. token=..., password: ..., common API tokens) Masking is applied consistently: in JSON reports (stdout / file) in log summaries 🔸 Strict config validation for environment-based secrets *_env fields must reference a valid environment variable missing or invalid values fail fast at startup clear validation errors are returned before execution begins 🔸 Enforced "no plaintext secrets in config" policy deny-list keys (password, token, secret, api_key) are rejected in config prevents accidental leakage through static configuration 🔸 Predictable failure behavior configuration errors stop execution early with a clear message and exit code Why this matters: Without this layer, even a useful tool can become a source of risk: secrets leaking into logs or CI artifacts silent misconfiguration due to missing env variables hard-to-debug runtime failures With these changes, SysGuard becomes safer to run in: CI/CD pipelines automated environments shared infrastructure It's still a learning project, but this step made it feel closer to something that could actually survive a basic security review. Next focus: Data Persistence #DevOps #DevSecOps #Python #Linux #Security #LearningInPublic #SysGuard

$285 million stolen. The entry point? A VS Code project with a weaponized tasks.json that ran malicious code the moment a developer opened the folder. Drift disclosed this week that DPRK operators spent six months building trust with contributors before delivering the payload. The attack didn't exploit a vulnerability in the traditional sense; it exploited how VS Code is designed to work. The "runOn: folderOpen" option in tasks.json executes automatically. No prompt. No confirmation. That's the implicit trust surface. This is exactly the gap I covered in my "Zero Trust in DevOps" talk at OWASP Austin. Developer workstations run tools that auto-execute by design (IDE extensions, package install scripts, task runners), and attackers are increasingly targeting that behaviour rather than writing novel exploits. The session recording is now up. It walks through eight specific techniques to harden the developer workstation, mapped to a maturity model you can start applying Monday morning. 🎥 Link to watch the recording and learn more about 4/1 disclosure in the comments Slides are available in the OWASP Austin Slack channel. #SupplyChainSecurity #ZeroTrust #DevSecOps #OWASPSPVP #OWASPAustin #DevEX #AppSec #ProdSec

At heart I am a geek who loves to read such fun topics like RISC chip architecture and software supply chain security. Not kidding, and my kids fall asleep to both immediately.  Evans presentation is a definite watch if you share similar interests, or concerned your org is not following software and supply chain security best practices  

I kept seeing the same pattern at repos: a secret slips into a commit, secret-detection-job CI catches it a few minutes later or sometimes it does not catch it , and everyone breathes a sigh of relief. But the more I thought about it — caught it where, exactly? After the push. After it landed in git-history which is in the BLOB . After it was already distributed to every system watching that branch. The detection worked. The prevention didn't exist. So I spent a weekend building something small: a local pre-commit scanner that checks staged changes for secrets before the commit is made. Integrates with mise, runs silently, blocks the commit if something looks wrong. https://lnkd.in/ga8B3EBd Still early — the rules need tuning and I want to add an easier way to manage false positives. But the core idea feels right: security that lives at the point of commit, not downstream of it. Has anyone else gone down this road? Would love to hear where it got complicated — especially around getting consistent adoption across a team. #devex #secertdetection #mise #github #platformengineering #devsecops #shiftsecurity #git

Security maturity in CI/CD is not just about blocking abuse, it’s also about detecting it when controls fail, without becoming a release bottleneck. Layered attack surface (each step reduces risk): - Install scripts → try to limit/disable arbitrary code execution during build time  - Pinned dependencies → visible control, but only at the top layer    → what about invisible transitive dependencies or composite actions you don’t see, pin, or audit?  - Cooldown strategies → helpful, but only to an extent    → the delay often just lets the wider community act as a canary  - Threat intelligence on packages → reactive and often lagging  - GitHub Actions hardening (pwn_request, injection controls) → reduces known attack paths  - Unprivileged sandboxing in CI → limits blast radius, not initial compromise  - Private registries / proxy controls → strong guardrails on what enters your pipeline    → but still focused on prevention and policy, not runtime detection of misuse  All of these reduce risk. What actually detects when something goes wrong? - When a compromised transitive dependency executes…   - When a nested action pulls malicious code…   - When secrets are silently exfiltrated…  How do you detect it without heavy instrumentation or impacting developer velocity? 👇 #GitHub #CircleCI #CI #CD #SupplyChainSecurity #PipelineSecurity #AppSec #DevSecOps #Detection #Canaries #Secrets #Dependencies

I have learned the hard way that a fast pipeline is not the same thing as a safe delivery process. If GitHub Actions only compiles code and runs unit tests, it is basically an expensive conveyor belt with trust issues.   The teams that get calmer releases usually add a couple of boring but powerful gates. Static Application Security Testing (SAST) and Secret Detection rules are a good starting point that blocks a pull request when it finds hardcoded secrets or critical injection patterns. Another is a Terraform policy check that fails the plan when it tries to create a public storage bucket or an IAM policy with wildcard admin access. This means obvious security mistakes get stopped before they turn into major security issues.   I strongly recommend putting those checks in the delivery path, not in a spreadsheet or in documentation. Security that only exists in a meeting is just decorative. Developers may grumble for a week, then everyone gets used to catching problems early instead of shipping them into production. #DevSecOps #SAST #SecretDetection #Pipelines #PR

GitHub published an incident review Rate-limiting rules added during past incidents had been left in place. Threat patterns evolved. Legitimate users started hitting blocks designed for attackers. Their diagnosis: "Without active maintenance, temporary mitigations become permanent, and their side effects compound quietly." GitHub was talking about infrastructure. I've seen the same pattern in the process: - the emergency standup that became a daily ritual nobody questions - the approval gate was added after one bad release, and it is still running - the reporting layer was built for a crisis that ended months ago. Every one of them was the right call at the right moment. The problem isn't that they were added. The problem is that nobody owns the exit condition! No expiry date, no review trigger, no one is asking: does this still serve the people doing the work, or just the memory of a problem that is already solved? Systems don't maintain themselves aaaand neither do the decisions baked into them. #SystemsThinking #SoftwareDelivery #EngineeringCulture