• tl;dr sec
  • Posts
  • [tl;dr sec] #332 - I've Joined OpenAI, fwd:cloudsec, AWS Well Architected Supply Chain Security

[tl;dr sec] #332 - I've Joined OpenAI, fwd:cloudsec, AWS Well Architected Supply Chain Security

Why I joined OpenAI to lead Cyber efforts, playlist of the latest cloud security talks, AWS' supply chain best practices

Hey there,

I hope you’ve been doing well!

🤔 New Job, Who Dis?

TL;DR: I’ve joined OpenAI to lead their Cyber efforts.

I’m joined by Mike Aiello, an awesome security executive and human. Mike was previously CTO at Secureworks, led product for Google Cloud Security from 0 → $B’s in revenue, and CISO at Goldman Sachs.

I was going to write a post describing all the details about joining, my thought process, etc. but it turns out there’s a lot to do at OpenAI and I’ve gotten very busy 😅 The post is started but not finished, will share when I can.

So here’s the short version.

Why
I was very happy at Semgrep and wasn’t looking for new opportunities, but when an OpenAI recruiter reached out, it seemed like a once in a lifetime company and opportunity that I couldn’t pass by.

During the interview process, when I spoke with my potential colleagues, I was impressed by how they were incredibly smart and kind, and genuinely, earnestly, cared about making a positive impact on the world. Several people, without me bringing it up, expressed to me that as models get better, they feel a moral responsibility to do what they can to secure the world’s software.

And now from the inside, I can see that the sentiment was genuine, and not a facade (you always wonder as an outsider). OpenAI has easily already spent millions securing open source and critical infrastructure that they haven’t yet claimed PR cred for doing.

I’ve long talked about the power of secure by design and eliminating vulnerability classes. Being at OpenAI makes that feel tractable in a way it never has before. I’m optimistic we, the security community, can meaningfully raise the world’s security bar over the next few years. Seriously.

Lastly, how I think about the decision is also well expressed by my friend Rami McCarthy, who, like with many things, annoyingly wrote a better version of what I would write in his post on joining Wiz. Similarly, I hope to “work for the security industry, at OpenAI.

I shared a LinkedIn post with a bit more details, feel free to say hi or share thoughts there 👋

P.S. tl;dr sec will continue, don’t worry. Also, I will continue to include high quality content from Anthropic, that is also unchanged. More on that below.

Sponsor

📣 State of SDLC Report 2026

The 2026 SDLC Security Report analyzed real-world development environments, codebases, and SDLC infrastructure to understand how risk is evolving and how software is built and shipped.

The TL;DR: Risk isn’t primarily driven by rare vulnerabilities. It scales through reuse, permissions, and automation across the SDLC.

The report explores:

  • AI copilots and developer tooling risk

  • Dependency concentration and supply chain exposure

  • Secret leakage trends

  • CI/CD and GitHub Actions attack paths

Learn how SDLC risk is reshaping application security.

Hm interesting, neat to see the SDLC is evolving and how it’s affecting AppSec 🤔 I like the stats and figures.

AppSec

1-Click GitHub Token Stealing via a VSCode Bug
Ammar Askar describes a bug in which clicking a github.dev link could steal a GitHub token with read/write access to all your private repos, by chaining a Jupyter notebook payload that exploits VS Code webview's did-keydown event forwarding to install a malicious extension. Neat write-up!

How We Cut Semgrep’s Taint Analysis Time by 75%
Semgrep's Austin Theriault walks through how the taint analysis engine was redesigned to run once instead of twice, cutting scan times by up to 75%. Taint analysis is used for vulnerabilities like SQL injection by tracking user input as it flows through code from sources to sinks, with propagators that carry the taint forward and sanitizers that clean it.

Semgrep's original 2023 architecture computed those configs during interfile analysis, then discarded them and recomputed during intrafile analysis, a design forced by OCaml's parallelism limitations before 5.0 that would have ballooned memory if all the state were kept in flight at once. Refactoring to merge both passes unlocked parallelization via OCaml multicore and reduced P95 scan times from 10 minutes to 7:30, with some large repositories seeing 3x+ improvements.

💡 One fun thing about working at Semgrep is you realize how much hard engineering goes into building static analysis tools. Very cool work, and fun to nerd out with the program analysis team, who are statistically likely to be some combination of a) French, b) have PhDs, or c) be from CMU.

Sponsor

📣 Key questions to ask any AI vendor

Vendors are claiming autonomy - but most are still requiring significant human oversight. And most security teams don't yet have a clear framework to evaluate the difference.

Join Sublime Security and Georgian on June 24 for a practical session on evaluating security AI. You'll leave with a clear autonomy framework, a trust-based evaluation path, and key questions to ask any AI vendor - including what good answers actually sound like.

👉 Register now 👈

Honestly, it is super useful to know the right pointed questions to ask vendors, as well as having a feel for what “good” and rigorous evals look like in practice.

Cloud Security

fwd:cloudsec North America 2026
The premier cloud security conference just uploaded the talks from their most recent event. Highly recommend. Many of the talks look great, and see the blog version of some below. Some additional talks I’m linking here so I can come back to them:

HazyBeacon and AWS Lambda Function URL Abuse
Qualys' Aniket Harne breaks down HazyBeacon, a campaign originally documented by Palo Alto Unit 42, where attackers used stolen IAM credentials to deploy AWS Lambda functions with AuthType: NONE Function URLs as command and control relays, making malware traffic indistinguishable from ordinary HTTPS calls to the lambda-url.<region>.on.aws domain. The chain starts with credentials harvested from public GitHub repos or developer phishing, validated through reconnaissance calls like aws sts get-caller-identity, then used to deploy a Lambda function under a benign name in an unused region whose public Function URL proxies traffic between infected endpoints and the attacker's real backend. The relay sits inside a separate compromised AWS account, which leaves the malware victim and the AWS account holder as two unrelated victims, often unaware they're connected until the bill or the abuse notice arrives.

Recommended mitigations: A Service Control Policy blocking AuthType: NONE Function URLs unless explicitly tagged, global CloudTrail logging, enabling VPC flow logs, and more.

💡 Honestly, pretty clever use of Lambda Function URLs.

Sub:jugation - Hijacking Cloud Identities by Recycling Namespaces in Global OIDC Issuers
Astrix Security's Tal Skverer describes Sub:jugation, a vulnerability class affecting GitHub Actions, GitLab CI, and Terraform Cloud where the global OIDC issuer model lets attackers reclaim deleted repository namespaces and mint JWTs with subject claims that match existing cloud IAM role trust policies. Any cloud role still trusting an orphaned sub claim hands over short lived AWS, Azure, or GCP credentials to whoever recreates the namespace. Astrix calls these forgotten roles Phantom Cloud Identities, and found that 14% of AWS identities and 24% of Azure identities trusting GitHub's global issuer point at namespaces that are no longer registered, with roughly 8 becoming exploitable each month through publicly available data alone.

GitHub has shipped the complete fix, adding random identifiers to sub claims so reclaimed namespaces can't mint matching tokens, while GitLab and Terraform have rolled out interim mitigations with full OIDC subject solutions still pending. Until those land, organizations need to audit every cloud identity trusting token.actions.githubusercontent.com, gitlab.com, or app.terraform.io, confirm the referenced namespace is still theirs, and either reclaim it or decommission the role outright.

Supply Chain

Well-architected best practices for software supply chain security
AWS's Trevor Schiavone and Desiree Brunner walk through defense in depth controls for npm supply chain attacks. Key mitigations include: replacing long-lived credentials with temporary ones via AWS CLI login, IAM Identity Center, or OIDC federation; implementing artifact signing with AWS Signer to cryptographically verify packages before production deployment; centralizing dependency management with AWS CodeArtifact's package group configuration to block typosquatting; and using Amazon Inspector's behavioral analysis to detect zero-day malicious packages.

Also: require MFA on maintainer accounts and multiple approvers, analyze CloudTrail logs for indicators of compromise, and leverage Software Bills of Materials to quickly assess blast radius during incidents.

Detecting and removing dangerous secrets on dev workstations before Shai-Hulud does
Guillaume Ross shows how to detect and prevent credential theft from developer workstations by combining bagel, an open source secret scanner, with Fleet, an MDM platform that uses osquery for telemetry, and an IdP conditional access policy. Bagel runs on a schedule through a LaunchAgent to find cleartext secrets in developers' home directories, Fleet reads the JSON output via its parse_json osquery table to evaluate it against a policy, and an IdP blocks SSO on non-compliant workstations until the secrets are remediated.

Guillaume ships the integration as Fleebag, a proof of concept repo with macOS installation packages for bagel, Fleet queries for findings, a policy query that passes only when scans are fresh and clean, and an example profile to grant bagel full disk access.

AI + Security

Quicklinks

Introducing the Agent Governance Toolkit: Open-source runtime security for AI agents
Microsoft's Imran Siddique released the Agent Governance Toolkit, an open source framework of seven packages that aims to address all 10 OWASP Agentic AI Top 10 risks by porting operating system, service mesh, and site reliability patterns to autonomous AI agents. The packages run across Python, TypeScript, Rust, Go, and .NET, and the toolkit plugs into each framework's native extension points across LangChain, CrewAI, LangGraph, LlamaIndex, OpenAI Agents SDK, and more.

The toolkit: Agent OS as the stateless policy engine (supports YAML, OPA Rego, and Cedar), Agent Mesh for cryptographic identity, Agent Runtime for sandboxing execution inspired by CPU privilege levels with an emergency kill switch, Agent SRE for applying service level objectives and circuit breakers, and the final three handling compliance, plugin lifecycle management, and reinforcement learning training governance.

System Over Model, Tested: Reproducing Mythos's FreeBSD Find on Local Open-Weight Models
John McIntosh reproduces Anthropic's Mythos discovery of CVE-2026-4747, an RCE in FreeBSD's RPCSEC_GSS authentication, using AISLE's nano-analyzer pipeline on two local open-weight models (gpt-oss-20b and gemma-4-31b-it). The models could find the bug, but the pipeline graduated 30 false positives that buried the real CVE. Rather than swap to a stronger model, John added one extra reachability filter stage using the same model weights that traces each finding back to an entry point, greps for callers, and checks whether the cited length is really controlled by the attacker or just set by the kernel, cutting false positives from 30 to 5 while keeping the real CVE valid. The full experiment is on GitHub.

💡 Here’s how I see it: the foundation model labs try to convince you that “all you need is the model” and security vendors (or individuals) argue “it’s all the scaffolding.” Ultimately, I believe the truth is: the model, the prompt(s)/Skills, scaffolding/architecture, and how much you’re willing to spend all matter. Improving each gets overall better performance. Improving the model can get you the same or better results with removed (or less) scaffolding, and improved scaffolding on top of better models will yield even better results (more true positives, fewer false positives/negatives).

At the end of the day, it all distills down, like most things in security, to: how much risk reduction are you getting at what price? My $0.02 at least.

Mapping AI-enabled cyber threats: Insights from the LLM ATT&CK Navigator
Anthropic’s Kyla Guru, Alex Moix, and Jacob Klein analyzed 832 banned accounts that misused Claude for cyber operations over one year, mapping 13,873 malicious actions across 482 MITRE ATT&CK techniques and developing the AI Risk Enablement Score (ARiES) to assess threat levels. They found the highest-risk actors weren’t distinguished by technical sophistication or number of techniques used, but by their use of agentic scaffolding to autonomously orchestrate entire attack chains, like one threat actor who weaponized Claude Code with MCP servers to autonomously execute reconnaissance, exploitation, lateral movement, and exfiltration.

Anthropic argues that the MITRE ATT&CK framework needs expansion to capture AI-native behaviors like autonomous killchain orchestration and real-time pivot decisions that don't map to existing technique IDs but represent the most dangerous evolution in AI-enabled cyber threats.

💡 This is really cool, and valuable context for the community on how threat actors are using AI. As mentioned in the intro, expect me to continue including solid technical work from Anthropic. I have many kind, extremely competent friends at Anthropic who I respect highly. I think the world is better off for having many companies and individuals working together to make the world safer.

Ultimately I think that’s the north star of all of us working in cybersecurity: making the world safer so all non-neck beards people live happy, fulfilling lives without having to worry about getting hacked, having their identity stolen, etc.

Misc

✉️ Wrapping Up

Have questions, comments, or feedback? Just reply directly, I’d love to hear from you.

If you find this newsletter useful and know other people who would too, I'd really appreciate if you'd forward it to them 🙏

Thanks for reading!

Cheers,
Clint

P.S. Feel free to connect with me on LinkedIn 👋