Paul Spicer

This is huge! AWS now requires specific claims in IAM role trust policies using OIDC for new/updated roles. This effectively mitigates the style of attack that I covered at DEFCON last year and the vulnerability AWS themselves introduced in Cognito/Amplify. Worth knowing, this does not retroactively apply to existing roles, only those that are modified/newly created. It is very cool to see AWS react to the research done by the cloud security community! https://lnkd.in/gjVZwysU

111

5 Comments

I’ve released a new version of promptmap. Now, it doesn’t just check for prompt injection attacks, it also detects issues like hate speech, harmful content generation, distractions, and more. It’s very easy to use and should be your go-to tool when deploying any LLM-based application. Just provide your system prompts and the model you want to use. It will automatically run attacks and show you which ones were successful. https://lnkd.in/e-pDDE7s

160

1 Comment

Recent experiments show automated adversarial capabilities are rapidly outpacing traditional defenses. While classic security hunts for code and network flaws, LLM red teams probe the model's reasoning space. Instead of buffer overflows, we're looking at prompts that make the model ignore safety rules or reveal private training data. Traditional pen testing tools won't catch the most dangerous LLM vulnerabilities. When an LLM can invoke external functions (APIs, code execution, plugin calls), attackers can move from simple prompt injection to orchestrated system compromise. We need new testing methodologies that blend human creativity with automation. Tools like PyRIT help with coverage, but they won't replace a skilled red teamer crafting multi-turn social engineering attacks. AI red teaming hunts for ethical and safety issues that traditional pen-tests wouldn't catch. This includes probing for bias, misinformation, and privacy leaks. Testing scope must include the model's outputs AND its integration points. Every function call the model can make is an attack surface that needs validation. In OffSec, these attack techniques are evolving fast. The move now is to set up dedicated red team programs focused on AI systems—get proactive, because attackers are already working to find those gaps. What are you seeing for effective LLM security testing? What's worked (or hasn't) in your offensive testing? #Cybersecurity #RedTeaming #InfoSec

33

4 Comments

It's easy to find online resources on how to exploit an exposed Docker socket in a containerised environment, but a lot harder to find information on how to do the same for the alternative containerd runtime. Given that Ive spent a bit of time figuring out how to do this, I thought Id share. This is part one: https://lnkd.in/g-7sPSFC

31

In DeepSeek's whitepaper they claim the cost of a training run is $6m. This figure is calculated based on how many hours a single training run takes, how many GPUs are required, and how much those GPUs cost per hour to rent. The estimate seems accurate based on similar estimates from other open source models. The people claiming it actually cost $1.3bn because the company outright purchased the GPUs are being deliberately misleading. It's like if I calculating the cost of my cross-country train trip by including the cost of building the entire train and rail network. It's pretty standard to estimate computational cost based on rented compute time. If you outright purchase hardware, you aren't just buying it and throwing it away after each use. You also likely aren't using it for a single purpose and letting it sit idle the rest of the time. That's why companies use the cost to rent compute instead. The people writing these posts/articles 100% know the difference between capital expenditure and operational expenditure, they're just hoping you don't. By conflating the two and adding them together, they can attempt to convince you that DeepSeek didn't just make a hugely impactful leap when it comes to LLM training costs, which it absolutely did.

179

18 Comments

Orca Security just announced the acquisition of Opus Security to bolster it's AI prioritization and remediation capabilities. https://lnkd.in/eBJFnvb4 Orca has been bridging the gap between CNAPP, CSPM, and CTEM for a long time. This acquisition puts them right into the thick of the race for self-healing systems. As always, it's going to come down to execution and integration, but assuming they have the technical capabilities to get it done, these features are exactly where the market is going. Automated remediation and prioritization are the future of self-healing systems. To quote the Mandalorian: #ESG #Enterprise Strategy Group (part of Omdia)

66

15 Comments

IMO, Trusted Publishing (along with provenance attestations) has been the single-best advancement for securing public package repositories. Firstly, it rids the need for long-lived tokens, which I can hope we all agree suck. But also, most people didn't realize that until recently (and still today with certain registries), nothing has tied source code repositories to the artifact published. Yes, you could publish a package you created, and link the source repository of any project, instead of your own 🙃. With Trusted Publishing, authentication is performed by exchanging OIDC identity tokens for short-lived and tightly scoped API tokens to authenticate with package repository publishing APIs. Provenance attestation similarly leverages OIDC, so it makes sense to use them in unison. During a workflow, you can build an artifact, attest to its origins, and publish to a package registry all at once. Enabling the registry to verify the origins of the published artifact.

51

6 Comments

Britain's National Cyber Security Centre recently issued a lukewarm verdict on passkeys as an authentication solution. On the Root Causes Podcast, Jason Soroko and I explore the problems with WebAuthn, including account recovery, spotty availability, inconsistent implementation, and lack of Linux support.  Audio: Video: https://lnkd.in/g6uHKii6

29

3 Comments

Earlier this week, Noma Security uncovered a rather critical vulnerability (CVSS 8.8) in LangChain’s LangSmith platform, a popular unified observability and evaluation suite for LLM-based applications. This discovery should raise flags for anyone building or deploying AI agents. The flaw, called "AgentSmith," revealed how seemingly trustworthy public agents shared via LangSmith’s Prompt Hub could silently exfiltrate API keys, intercept prompts, and tamper with LLM outputs, all by routing traffic through a proxy controlled by the attacker. Nice :) This is yet another wake-up call for anyone betting on AI to boost productivity. The more we delegate to agents, the more we expose ourselves to a new breed of supply chain threats, not from libraries or dependencies, but from the agents themselves. What’s most alarming is how invisible this threat was. These agents weren’t obviously malicious. They didn’t trigger alerts. And traditional product security tools wouldn’t raise an alert in this case. The issue is exacly that - Trust models for AI has to evolve from the basic ProdSec approach. If you're using LangChain, LangSmith, or experimenting with agent-based automation, now is a good time to review what’s running under the hood... Kudos to Gal Moyal and Sasi Levi from the Noma Security research team for surfacing this. Important work. Link to article - https://lnkd.in/e3mh9Jzk

80

6 Comments