All Posts

A big thank you to Bryson Bort for having me on his Unicorn Dispatch Live stream today to talk AI security and vulnerability management.

Months after the announcement of Project Glasswing, we're finally seeing the uptick in CVEs being reported: Linux kernel 442 CVEs over three days; Microsoft 620 bugs in July's Patch Tuesday; Google Chrome 433 bugs; and Cisco, Adobe, and Oracle rolling up thousands of individual flaws into larger batches. What's clear is that Project Glasswing and similar industry efforts, like OpenAI's Patch the Planet, are beginning to produce results. I've met with a number of companies on this topic over the last few months, and my recommendation remains the same. Companies must move toward adopting agentic vulnerability management. Companies must move beyond CVE-based risk assessment and instead combine those raw vulnerability management scan results with their exposures and threat model, and most importantly agentically review on the individual CVE level the exploitability of a vulnerability on a resource. We are not remediating vulnerabilities. We are remediating risk on resources running in an environment. Companies shouldn't be afraid of large patch dumps like these. Instead, they should be doing new work to ensure they are patching the correct vulnerabilities and asking internal teams to take on the correct work. That new work? Building AI agents focused on identifying which CVEs are exploitable in *your* environment. The new CISA BOD 26-04 guidelines, which prioritize exploitability and real-world threats over arbitrary CVE-assigned risk, give you a credible resource to change your vulnerability management policy and patching SLAs. The fact is that the vast number of CVEs are not exploitable due to other compensating controls, which gives companies the flexibility to address these vulnerabilities within maintenance windows. We're not at a drop-everything-and-patch-faster moment. We're at a turning point in the industry where we need to take on different work to ensure we keep up with a rapidly evolving playing field.

Today I released a piece of work I've been developing over many months: the AI Guardrails Maturity Model. It's a free, open reference that guides engineers on effective AI security guardrails, and where to go next as a team levels up their controls. https://lnkd.in/edEWJsJ9 I built it for two reasons. First, my own work at Netlify developing agents for our Security Team. Building agentic systems in production surfaces security gaps quickly. It's essentially like handing access keys to an intern who just got back from happy hour. Any problem you have gets amplified fast. Second, I've had a number of conversations through IANS with organizations working through every maturity level of AI security. Many of these discussions come back to the security controls around traditional and agentic systems: where to be now, and what comes next. There's excellent guidance out there from NIST, OWASP, MITRE, and CISA, but none of it gives you the sequence. Which controls come first, which can wait, and which only matter once you go agentic. So I built the sequence: crawl, walk, run. 36 controls across 13 categories, each placed at the maturity level where it should first appear, from Basic through Leading Edge. One thing I want to be clear about: this is not a bingo card. The goal is not to implement all 36 controls. Many will be irrelevant to your system, and that's expected. Scope it to your architecture first, build the basics, and level up from there.

"Guardrails" has become one of the most common words in AI security — and one of the most hand-wavy. As agentic systems get production credentials, internal ...

Supply chain attacks often target GitHub credentials, with a goal of stealing internal repositories of organizations. Previously, the goal was credential harvesting; finding secrets buried in a repo's git history. But the threat has evolved. With the advent of current AI models (e.g. Opus 4) adversaries can now find previously unknown vulnerabilities in those stolen repos they've been sitting on. When future models like Mythos become generally available, the skill level required to find advanced vulnerabilities in those stolen repos will drop to near-zero. Security teams can take some steps now in preparation. 1) Use current models to audit your codebases for vulnerabilities, and fix them. You can and should use AI assistance to speed this process. 2) Patch now. There will be many previously unknown severe vulnerabilities that will be discovered and fixed in open-source and commercial software while Mythos is in a private beta. Staying ahead of these updates will mean less to fix later. Keeping software up-to-date is important, since applying a patch level fix is often a trivial process, where major and sometimes minor version bumps require more effort.

I just read an article that claims that the number of AI agents ignoring human instructions and violating guardrails is on the rise. This is not a real thing ...or it least it shouldn't be. For guardrails to be effective they need to exist outside the agent's nondeterministic state. There should never be a situation where an AI agent mass deletes a lot of data in production, because it simply should never have the permissions to do so. Asking an agent nicely to not do something is not a guardrail.

🎉 It's truly an honor to have been named as an IANS Faculty member. I'm incredibly humbled to join a group that includes some of the most influential and distinguished people in cybersecurity. Through my work with IANS, I advise Fortune 500 companies and security leaders on complex real-world cybersecurity problems. My areas of specialization include: cloud native security & architecture, application & API security, offensive security (red team, purple team, penetration testing), vulnerability management, and AI/LLM security/guardrails. My role at IANS is in addition to my position at Netlify where I work to secure our 11 million+ developer customer base! 🙂

Some Netlify customers have reached out asking about the potential impact to websites of US-based organizations due to the ongoing conflict between the US and the IRGC. From what I currently observe, there is not any specific active cyber threat to websites of US-based organizations by the IRGC. The consensus I've read by experts in this space is that the IRGC and their proxies are dealing with a much larger threat at the moment and likely will not be focused on attacking miscellaneous targets. That said, critical US infrastructure should be operating on heightened risk due to the potential of being targeted by the IRGC or hacktivists. Hacktivists may also look to target websites for defacement. Our recommendation is to review the security of your Netlify account. Tools like our Security Scorecard can make recommendations on how to strengthen security posture.  Ensure that all users have MFA enabled and are scoped to the correct level of access.  It's also recommended to review environment variables configured for sites, and mark secrets as secrets to ensure they are protected by our Secrets Controller.  It's also recommended to scope secrets to the correct levels of access on your site. I'm happy to address any specific questions anyone may have.

It's back! The wildly insecure vibe coded Retro 90's Chat app is now being secured by a set of home-grown Claude Code security skills. When I demoed this several months ago, "skills" didn't exist. Security controls were applied via .md files, which worked but was cumbersome. With the introduction of skills we gain a better result with additional efficiency and modularity.

I have huge personal/professional news to share! I've been named an IANS Faculty member. 🎉 I'm incredibly honored and humbled to join a group that includes some of the most influential and distinguished people in cybersecurity. I don't view this as having "made it," but rather as a reminder that every day I need to show up and earn my place through hard work. I'm very much looking forward to the opportunity to advise others in the industry. I especially want to thank Jon Zeolla, who nominated me to begin the process last year. And... I'll still be continuing my role at Netlify as Principal Security Engineer, as I celebrate 3 years at the company! https://lnkd.in/eCCmeE9S | 18 comments on LinkedIn

I'm really proud of how the team at Netlify worked to mitigate the risk of #React2Shell for our customers. This post highlights some of our ongoing work, and some of the attack trends we have observed over the last couple of weeks. https://lnkd.in/euXSq9ts

Resharing this post I wrote several weeks ago, in light of another incarnation of the "Sha1-Hulud" attack on the npm ecosystem which emerged overnight. If you are unsure if you were affected, your package.lock file will always show the exact version of the npm package installed, even if using fuzzy versions in your package.json file. Information about this incarnation of the Sha1-Hulud threat is still emerging, but it seems to follow the same pattern as the last attack, where data was exfiltrated via the creation of a public GitHub repository. Validating that this repo does not exist in your organizational GitHub accounts and those of employees is important. It should be noted though that for the previous round, GitHub themselves acted rapidly containing the repositories and notifying affected individuals. Due to the nature of how the worm worked during the previous outbreak, it was less likely to be able to exfil data from CI/CD pipelines (like for example when building a site on Netlify). Usually in this execution context, general write access to GitHub is not available. For this reason, it seems that the more likely target of this attack is developer workstations, who much more likely will have both environment variables and an active GitHub session.