Coder Legion - Recent posts tagged appsec

Cybersecurity Is a Developer's Responsibility, Not Just the Security Team's

Fri, 30 Oct 2026 06:22:26 +0000

Cybersecurity is often treated as something that happens after an application has been built. Developers focus on functionality, deadlines, and user experience, while security is left to a separate team.

But what if some of the most important security decisions happen before an application is even deployed?

As a software developer and cybersecurity enthusiast, I've been thinking about how the small decisions we make while writing code can have a major impact on the security of the systems we build.

For Cybersecurity Awareness Month, I want to highlight a simple idea: building secure software starts with everyday development habits.

1. Never trust user input

Every application receives input from somewhere: a form, an API request, a mobile application, or another service.

The mistake is assuming that this input is always valid or trustworthy.

Depending on how it is handled, untrusted input can lead to SQL injection, cross-site scripting, or other vulnerabilities.

For example, avoid constructing SQL queries by concatenating user input into a query string. Use parameterized queries or a trusted ORM that safely handles query parameters.

Security begins by treating external input as untrusted and validating it at the appropriate boundaries.

2. Keep secrets out of your source code

API keys, database passwords, signing keys, and access tokens should never be committed to a public repository.

Even private repositories can be exposed through compromised accounts, misconfigured permissions, or accidental sharing.

A few habits make a difference:

Store application secrets in an appropriate secret manager or secure configuration mechanism.
Use environment-specific configuration.
Scan repositories for accidentally committed credentials.
Revoke and rotate exposed secrets immediately.

One important lesson: deleting a secret from the latest commit does not necessarily remove it from Git history. Treat an exposed credential as compromised.

3. Authentication is not authorization

Authentication answers the question: Who are you?

Authorization answers: What are you allowed to do?

A user may successfully log in but still have no right to view another customer's transaction, change another person's account details, or perform an administrative action.

Applications must enforce authorization on the server for every relevant operation. Hiding a button in the interface is not a security control.

This is particularly important in financial applications, where an authorization failure could expose sensitive data or enable unauthorized transactions.

4. Protect your APIs

Modern applications depend on APIs to exchange data between mobile clients, web applications, and backend services.

A secure API should consider:

Strong authentication and correct token validation.
Object-level authorization.
Rate limiting and abuse prevention.
Safe error messages.
Request validation and replay protection where appropriate.
Logging and monitoring without exposing credentials or sensitive personal data.

Having an access token does not automatically make an API request safe. The backend must still verify that the caller is entitled to perform the requested operation.

5. Make security part of your workflow

Security does not have to be a final checklist before deployment.

It can be incorporated into everyday engineering through code reviews, automated tests, dependency scanning, static analysis, secret scanning, and threat modelling.

Before merging a change, ask:

Could this expose sensitive information?
Can another user access a resource they do not own?
Are errors revealing internal implementation details?
Have I introduced an unsafe dependency or configuration?
What happens if someone sends an unexpected request?

These questions will not eliminate every vulnerability, but they help make security a normal part of engineering rather than an afterthought.

Final thoughts

Cybersecurity is a shared responsibility, and developers are in a strong position to make a difference.

We do not need to know everything about security before we start making better decisions. We can begin by understanding common vulnerabilities, learning secure coding practices, and testing our assumptions.

This Cybersecurity Awareness Month, I'm challenging myself to keep learning, build more secure applications, and share practical lessons with the developer community.

What is one security practice you believe every developer should adopt? I'd love to hear your thoughts.

Oracle AI Security Mesh Gives Each Agent Its Own Identity and Just-in-Time Permissions

Wed, 28 Oct 2026 13:45:30 +0000

An AI agent that hunts for vulnerabilities needs access to the systems it tests. That is the uncomfortable part of agentic security. The tool that finds the weak spot also holds keys to the house.

On Tuesday at Oracle AI World in Las Vegas, Oracle announced a managed service that tries to deal with both halves of that problem. Oracle AI Security Mesh uses OpenAI's frontier cyber models, combined with Oracle's testing tools and the context customers supply about their own systems. It covers applications and infrastructure on Oracle Cloud Infrastructure, in other clouds, and on-premises.

According to Oracle, the models reason through how an application behaves and investigate how a weakness could be exploited. They help security teams rank the most serious risks, and they supply evidence, including reproduction steps and test results. When a fix is proposed, the service tests it within the approved scope and checks the effect on expected application behavior. Customers approve each change before Oracle AI Security Mesh applies it.

The part that matters most to anyone building agents is how Oracle says it controls the agents themselves. Each agent runs with its own identity, a defined task scope, and permissions granted just in time. Separate monitors watch for activity outside the approved scope and can stop it. In other words, the testing agents get the same treatment a security team would want for any agent it deploys. Identity, scope, short-lived access, an independent watcher, and a human sign-off before anything changes.

Customers decide where testing is authorized and control its scope. Oracle runs the safeguards meant to reduce the risk of outages or disruption during testing. The pitch, as the OpenAI announcement puts it, is that customers don't have to build and operate their own offensive and defensive agent systems.

"As AI agents take on more responsibility, enterprises need security that can keep pace with how these systems operate," said Phil Newman, senior vice president of Security and Identity at Oracle. Johannes Landgraf, head of cyber at OpenAI, said the combination can help security teams "investigate complex issues, prioritize critical risks, and accelerate remediation while maintaining the controls they require."

Oracle paired the service with two existing pieces. The first is OCI Identity Assurance, which puts the human side of the problem in view. Before a sensitive action such as releasing a payment or changing access permissions, it can use biometrics to verify the identity and presence of the person approving it. Oracle says that in agent workflows, this helps establish that an approval came from a verified person. It is built into OCI Identity and Access Management and works across Oracle Cloud services, including Oracle applications.

Oracle also pitches the same checks for hiring and ongoing access. It combines identity document checks with biometric verification to help spot impostors, and it names North Korean IT worker schemes as an example. Later biometric checks can catch impersonation and account handoffs by confirming that the person using a resource matches the enrolled user.

The second piece is OCI Zero Trust Packet Routing, which sits underneath the agents. Oracle launched it in 2024 and says it was the first cloud provider to implement the emerging open standard. Policies are written in human-readable form and define which resources can talk to each other and which paths can reach sensitive data. Traffic to a protected resource has to be allowed by both those policies and the existing network controls. Oracle says the protection holds as network configurations change, which helps keep a misconfiguration from exposing a resource.

For AI workloads, the point is that enforcement happens below the application and the agent. A compromised agent can't talk its way around a network rule it never sees. Oracle says this helps contain compromised workloads, block lateral movement, and restrict routes for data exfiltration. The implementation follows an open specification developed through an industry initiative, with an open-source reference implementation.

Plenty is still missing. The announcement doesn't give an availability date or pricing. It doesn't say which OpenAI models power the service or how Oracle measures the quality of its findings and fixes. It offers no false-positive rates and no data on how often a proposed fix breaks something. Nothing explains how the independent monitors decide that activity is out of scope, or how long a just-in-time permission lasts. And testing live systems is risky, so teams will want to know how the service behaves against production.

Even so, the design is worth copying. If you build agents, whether for security or anything else, the checklist is short. Give each agent its own identity. Scope each task. Grant access only when needed. Put an independent monitor over the agent. Require a verified human to approve anything that changes a system. Oracle says it built those into a product. Teams building their own agents can start from the same list.

I've been gone for 5 months. Here is what I built while I was away (and how you can help me test i

Wed, 28 Oct 2026 12:25:11 +0000


Hey CoderLegion! 👋

It’s been a minute since I last posted here. I went heads-down into the trenches of building, and to be honest, I neglected this community while focusing heavily on LinkedIn.

But I’m back, and I brought something with me.

When I first shared Permi here, it was a basic CLI security scanner. Since then, based on feedback from data-protection lawyers, CISOs, and senior engineers, it has evolved massively.

## What Permi does now:

- **Nigerian-Specific Scanning:** Catches hardcoded BVNs, exposed Paystack/Flutterwave keys, USSD flaws, and PII in logs that global tools miss.
- **AI Noise Reduction:** Cuts out ~95% of false positives so you only see what's real.
- **Automated Compliance:** It maps findings to NDPA/CBN controls and generates an automated Excel Readiness Workbook (yes, it calculates the final compliance score and tracks evidence provenance).

## Why I’m posting:

I am moving into a critical beta phase. I don't just want downloads; I want technical feedback. I need developers and security folks to break it, test it, and tell me what’s missing.

## How you can help (Zero pressure):

### Option 1: Run it yourself

You can install it in a Python environment and run it on a staging/demo repo:

```bash
pip install permi
permi setup --api-key YOUR_API_KEY_HERE
permi scan ./your-codebase

(The API key is free from openrouter.ai for a few test calls).

Option 2: Let me run it for you

If you don't feel like setting it up, just drop a link to a public GitHub repo in the comments or DM me. I'll run the scan on my end and send you the PDF report + the automated Excel workbook.

If you test it, please reply here or DM me. Tell me: Did it catch anything real? Was the setup smooth? What frustrated you?

Let's build something useful for the Nigerian/African ecosystem together. 🚀

Hashtags: #Python #CyberSecurity #AppSec #DevTools #OpenSource #NDPA #NigerianTech

Oracle Plans Post-Quantum TLS for Java 8 and 11 in Late 2027, and Wants Testers Now

Tue, 27 Oct 2026 23:35:19 +0000

Security teams are starting to ask a question platform teams don't like: what's our plan for post-quantum encryption? For shops still running Java 8 or 11, the answer has mostly been a shrug.

At Oracle AI World in Las Vegas this week, I got a firmer one. I sat down with Georges Saab, senior vice president of Oracle's Java Platform Group; Donald Smith, vice president of product management for Java Platform; and Bernard Traversat, vice president of software development for the Java Platform Group. I asked about the schedule for hybrid post-quantum key exchange in TLS 1.3.

The feature is generally available in JDK 27. It arrived in JDK 25 with the October critical patch update. I laid out what comes next as I understood it: Java 21 and 17 in the first half of 2027, Java 11 and 8 in the second half. The team confirmed that was right.

Those are half-year windows, not release dates. And there is a condition attached.

Customers have been asking Oracle for post-quantum support as fast as possible. Now that it ships, the team wants them to use it. Many reply that they'd rather have it backported first. Oracle's answer is to test what already exists.

Smith said the key to stability is "just getting people using what we have, even though it's only in the latest."

There is a chicken-and-egg problem. The specification was only finalized in February, so many of the endpoints a Java client talks to don't support the hybrid exchange yet. Smith called the backport itself the hard part. For the next two to three months, the team is focused on stability so the backport starts from solid ground.

Feedback comes from two places. One is customers. The other is a group in OpenJDK that works with major third-party library projects, including Apache and Eclipse, and with the OpenSSL community.

Performance is the other worry. Java 8 shipped years before TLS 1.3 was final, and the team had to backport it. That taught them the backport has to be stable and fast on old hardware. A team tracks performance benchmarks on every release, including the new algorithms, he said. He gave no numbers.

If you run Java 8 or 11, waiting for the backport and then starting your testing is the slow path. Point a JDK 25 or 27 client at your post-quantum-capable endpoints, such as a gateway or proxy, and report what breaks. Oracle says it needs that feedback.

Backports aren't the only way out. Saab said he now regularly meets teams where most workloads are on Java 21.

He described the upgrade ladder this way. Going from 8 to 11 is the hardest step. Each step after that gets easier. "21 to 25 super easy," he said. The platform has been changed so that code survives upgrades better than it used to.

When teams do get stuck, the cause is usually outside the JDK. One is third-party libraries that nobody maintains. The other is the oldest problem: "when people used APIs that were not part of the public API," Saab said.

For finding those problems, Traversat pointed to Oracle's Java Management Service. It analyzes the APIs an application uses and reports deprecated APIs, changed behavior, and JVM argument changes between versions, such as 11 to 17 or 25. After that, he said, you still run the testing you use to certify the application.

I also asked how a team should verify code that an AI agent has refactored. Smith was direct: "I don't have a swift answer for that one." Saab said migration tooling is being built by other people. His team has helped groups inside Oracle migrate, to learn what the JDK could do better. Would the JDK team build migration tools itself? "I'm not saying we will never do that," he said.

So if you plan to use agents on a legacy Java codebase, the tools will come from outside the JDK. Verification still falls to your test suite.

The other date on your calendar is the patch schedule. Oracle announced in the spring that it is moving to monthly security updates across the company, not just for Java. Smith said the Java team will phase this in. "Next year we'll probably do 10 security updates and then it'll be every month thereafter," he said.

AI is part of the reason. "It's clear that AI has increased the rate at which you find vulnerabilities," Smith said. He added that it has also improved the team's ability to fix them.

He worried at first that system administrators would push back. They haven't. "The feedback is like nobody is surprised by this," he said. Some organizations will still have to adapt. A team on a quarterly change window is the obvious example.

Two items have no dates: non-hybrid key exchange and Merkle certificates. Smith said the work follows the IETF specifications and he wasn't sure enterprises could plan around it. His advice was to follow OpenJDK development. The issue trackers are open, and code already exists.

That caution is deliberate. "Never get ahead of the spec," Smith said. He pointed to the original java.util.Date as the example. An early implementation gained traction, it wasn't the best design, and the proper replacement took 10 to 15 years to arrive. Traversat added that anything shipped in the platform has to be supported for years, so Oracle moves conservatively.

For Java teams, the planning date is the second half of 2027 for Java 8 and 11. The work that decides whether that date holds starts now, and Oracle is asking for your help.

HiddenLayer: A Hijacked LLM Gateway Can Turn Your Coding Agent's Own Permissions Against You

Thu, 22 Oct 2026 14:00:00 +0000

Most security talk about AI coding agents focuses on the model. Will it run a bad command? Can a poisoned README trick it? New research from HiddenLayer looks somewhere else: the plumbing between the agent and the model.

In a report released today, HiddenLayer researchers Esteban Tonglet, Divyanshu Divyanshu, and Kasimir Schulz show that anyone who controls an inference server or LLM gateway can quietly learn how a coding agent is configured. Then they can forge tool calls that ride on permissions the developer already granted. The agent runs them. The developer sees nothing unusual.

Why the middle layer matters

Plenty of developers don't send traffic straight to one vendor. They use open harnesses like OpenCode, Cline, and Hermes, pointed at open-weight models served through Ollama, vLLM, or providers like Together AI and Fireworks. Many organizations add a gateway such as LiteLLM to centralize API keys, routing, logging, and policy.

Each layer relays requests and responses, so it sees prompts, tool definitions, history, and tool output. LiteLLM's async_pre_call_hook and async_post_call_success_hook let custom code read or rewrite that traffic. That's useful for guardrails. It's also exactly what an attacker wants.

HiddenLayer describes two ways in: a malicious Ollama wrapper that listens on the default port, 11434, and forwards to the real service, or a supply chain compromise of a gateway's package, plugin, or container image.

Step one: watch the clock

The attacker doesn't need to change anything to start learning. By timing the gap between a tool call and its result, a proxy can tell whether the agent paused for a human to approve it. File reads normally finish almost instantly. A pause of several seconds suggests a prompt.

The signal is strong. Across more than 4,000 captured sessions, just 4.7% of calls to fast tools landed in HiddenLayer's ambiguous range, compared with 25.5% of shell calls. Across more than 35,000 file reads, only 1% did.

Shell commands are noisier. So the proxy can slip timing code into a script through an auto-approved file edit, or wrap a command in a timer. Either way, the timing output is stripped before the user sees it.

Hiding that wrapper is easier than you'd think. Agents routinely generate long build commands full of pipes and redirects. Users scan for rm, sudo, or curl piped to a shell. A small addition in a 20-command line blends in. The researchers used a Tree-sitter Bash parser to score complexity and pick hiding spots.

Step two: read the configuration

Harnesses also give a lot away. Codex headers start with codex-tui. Claude Code identifies itself as claude-cli. Hermes uses a generic OpenAI SDK user agent, but its default tools (terminal, write_file, patch) reveal it.

Some harnesses go further. Codex includes its permission settings in every request: sandbox mode, writable paths, network access, and approved command prefixes. Claude Code sends its working directory, OS, Git status, and a Bash tool schema that includes a dangerouslyDisableSandbox option.

A proxy can also insert its own reads of files like CLAUDE.md, AGENTS.md, or .cursorrules, then strip the call and result. The model never knows.

Step three: use what's already allowed

HiddenLayer ran two demos. In the first, Hermes ran in manual mode, which only prompts for commands it considers dangerous. When the user asked Hermes to read a Python file, the proxy inserted file edits that added a heartbeat_ok() function. That function collected environment variables and SSH keys and sent them to an attacker's webhook. The proxy then ran the file with python3 and removed the function. Every step ran without a prompt.

In the second, Codex had the git prefix approved and a writable .git directory. The proxy forged this call:

git -c diff.external='sh -c "cat .env"' diff --no-index /dev/null .env

Codex ran it without asking and returned the contents of .env. Git's helper options can launch other programs, so an approved git prefix is broader than it looks.

There's a slower option, too. The gateway rewrites a dependency name, say requests to reqiests. Nothing happens until someone installs dependencies later.

This isn't hypothetical

LiteLLM shipped two malicious PyPI versions, 1.82.7 and 1.82.8, on March 24, 2026, after attackers got hold of a maintainer's publishing credentials. And an April 2026 study of 428 third-party LLM routers by University of California researchers found nine injecting malicious code and 17 abusing researcher-planted AWS credentials.

What developers can do now

HiddenLayer's report focuses on the attack, not a checklist. Here's what I'd take from it:

Treat gateways and inference servers as part of your trust boundary. Pin versions, verify artifacts, and control who can change hooks and callbacks.
Be careful with free or unknown routers. Cheap access isn't worth handing someone your traffic and keys.
Keep approvals narrow. Blanket approvals for git, python, or file edits give a proxy room to work.
Keep secrets out of the agent's reach. Don't leave .env files, SSH keys, or cloud credentials where the agent can read them.
Watch outbound traffic from developer machines and build systems.

Coding agents are doing a lot of good work. But sandboxes and approval prompts assume each tool call came from the model you chose. HiddenLayer's point is that this assumption no longer holds. The security boundary includes every system that can shape what the agent runs. And the teams that build and deploy these agents are responsible for that whole path.

PHP2Shell: Two 9.2-Rated Flaws Reach Back to PHP 5. Here's the Plan for EOL Teams

Thu, 22 Oct 2026 13:00:00 +0000

PHP shipped emergency patches on October 21 for two critical flaws now known as PHP2Shell. Both are rated 9.2 under CVSS v4.0. Both can let an unauthenticated attacker run code on your server.

The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run a supported branch, update and restart your PHP workers. That part is simple.

The harder question is what to do if you run a version that no longer gets community patches. A lot of teams are in that spot.

I asked Matthew Weier O'Phinney about it. He's principal product manager for Perforce OpenLogic and Zend, and he sits on the PHP Foundation board. Perforce sells extended support for end-of-life (EOL) open source software, so keep that in mind when he talks about extended support. But he also had a close view of how this disclosure played out.

What the flaws do

CVE-2026-109618 corrupts memory when PHP hits an out-of-memory error in the middle of a request. CVE-2026-109619 involves stale global state. PHP keeps pointers to request data after that memory has been freed.

Weier O'Phinney put it in plain terms. "An attacker can create one or more payloads that simulate large file uploads, or multi-file uploads, that hit configured memory limits for the PHP application," he said. Because of how PHP handled memory and errors at that moment, the attacker could end up running system commands on the server.

The attack doesn't need a vulnerable application or a public upload form. And the timeline was tight. Details leaked on October 20, a day before the coordinated release. Security firm Sansec reports that Cloudflare saw attacks hours before the patches shipped.

It's not just mod_php

PHP's advisory named Apache's mod_php as the highest-risk configuration. Some early coverage stopped there. Weier O'Phinney says that's too narrow.

"These vulnerabilities affect every single Server API (SAPI) provided by the language, because their roots are deep within how the engine manages memory and handles errors," he said. "If you run PHP, your application is affected, plain and simple."

mod_php may be the easiest path in. But PHP has also confirmed remote code execution against PHP-FPM under the right application conditions. If you run FPM behind Nginx, you're not off the hook.

Workarounds buy time. They don't fix the problem.

The early advice was to turn off session upload progress and remove memory limits. Weier O'Phinney says those steps help, but only so much. "They just change the size of the file upload payloads the attacker needs to use to exploit the system," he said.

He's more positive about two other measures:

A web application firewall (WAF) that limits which paths accept uploads, or any user submission
AppArmor or SELinux to restrict PHP's access to system binaries

Both are good defense-in-depth. But he warns that creative attackers can still find ways around them if the PHP runtime underneath is vulnerable.

PHP says the same thing. Updating is the only complete fix. If you removed the memory limit as a stopgap, put a container or cgroup limit in place, and restore a finite limit once you've patched.

The end-of-life problem

Here's where it gets uncomfortable. According to Weier O'Phinney, every PHP version before 8.2 is past community support. And 8.2 reaches end of life at the end of this year.

These flaws trace back to the PHP 5 series. "If you're running PHP 5, PHP 7, or early PHP 8 versions, you will need to audit your applications and deployments," he said.

He sees two paths:

Use a commercial long-term support (LTS) provider. Several have patched EOL versions. Perforce Zend patched PHP 7.2, 7.3, 7.4 and 8.1 in coordination with the PHP Security team. If you already have a provider, confirm it shipped patches for your version.
Start migrating to a community-supported version. That means 8.2 or later. Since 8.2 is nearly at end of life itself, a migration that stops there only buys you a couple of months.

If you have neither, his advice is to pick one today.

AI changed the clock

The backstory matters here. A security audit sponsored by the Sovereign Tech Agency and the PHP Foundation found these attack vectors last year. But the security team couldn't find a practical way to trigger them. They treated the flaws as largely theoretical and kept working on them off and on.

Then, this past August, two independent researchers found the same issues within days of each other. Each was using a frontier AI model. Each built a way to exploit them. The PHP Security team had to move them to the top of the list.

That's the real shift. A bug that sat in the "theoretical" pile for a year became practical in a matter of days.

Weier O'Phinney sees the same pattern across open source. The cURL project has been handling a flood of AI-discovered reports for two years. Spring has seen a big jump in reports this year. And those reports still need people to review them. Maintainers have to confirm that each patch works, doesn't break existing behavior and doesn't add new flaws. Many AI-generated reports also overstate severity, which takes more time to sort out.

For EOL software, this is the core risk. Discovery is speeding up. Patches for unsupported versions aren't.

Migration or extended support?

Weier O'Phinney is clear that migration is the goal. Current versions get new features and security fixes first, and the rest of the ecosystem tends to follow the latest releases.

But he's also realistic. Continuous upgrades take discipline, solid testing and QA, and a DevOps team that can roll releases out and roll them back. Some companies also face regulatory reviews every time they move to a new feature release. That costs time and money, so migration gets pushed back.

"So adopt those new versions if you can, but have a plan for when you cannot," he said.

That's fair advice, and it's worth taking at face value. Extended support is a bridge, not a destination. If you're evaluating a provider, ask one simple question: how fast did it ship PHP2Shell patches for your version? The answer tells you a lot.

How the disclosure worked

Weier O'Phinney knew for a couple of months that big security patches were coming. He didn't know the details. "That's a good thing," he said. Fewer people in the loop means less chance of a leak.

The PHP Foundation now employs a small team that coordinates security work between researchers and the PHP project. One of them contacted Weier O'Phinney in his role at a commercial LTS provider to line up releases. In more than 20 years at Zend, that was a first for him. The PHP Security team worked with Zend's packaging team and reviewed its patches so both were ready on release day.

His bigger concern is capacity. The PHP Security team is small, and the volume of incoming reports keeps growing. He'd like to see it staffed well enough to coordinate like this more often. His ask: if your company depends on PHP, consider donating to the PHP Foundation.

What to do this week

Find every PHP runtime you have. Check servers, containers, base images and hosting accounts. Trust php -v, not your documentation.
Patch supported branches now. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart PHP workers so the new code is actually running.
Check EOL versions separately. If you use an LTS provider, confirm it has shipped fixes. If you don't, choose between getting one and starting a migration.
Treat workarounds as temporary. Undo emergency config changes once you've patched.
Keep the extra layers. A WAF and AppArmor or SELinux are worth having after the patch, too.
Plan for more of this. AI-assisted discovery isn't slowing down. Budget time for triage and upgrades, not just for incidents.

PHP2Shell will get patched on most supported systems this week. The teams still exposed next month will be the ones running PHP that nobody owns. Now is a good time to find out if that's you.

Use AI to Get Smarter, Not Lazier

Tue, 06 Oct 2026 18:40:48 +0000

I promise this isn't another post saying AI is making us dumber.

AI does make us faster, and we can't afford to give that up. But if you're not careful, "faster" quietly turns into "I shipped this and can't explain it". This post is about a way to use AI that keeps the speed and leaves you understanding what you did.

I'll explain the problem first, then walk through one of my day-to-day tasks, triaging static analysis (SAST) findings, done two ways: with a one-line "just triage it" prompt, and with AI used to help me understand. Both reach the same verdicts. Only one of them leaves me able to defend those verdicts.

Prefer video?

https://youtu.be/z_A_UVAFx0M

️ The long way is where the learning happens

Every task is a trip from "task" to "done". The long way is reading, searching, trying, failing and trying again. It's slow, but that's where you pick up tools, debugging habits, patterns, mental models, trade-offs and skills.

Humans take the path of least resistance, so we've always looked for shortcuts. Copying an answer from Stack Overflow was the classic one.

⚡ AI is the ultimate shortcut

Now a huge share of our tasks can be done, fully or partly, by telling AI: "do it for me". Most of the time the result is good enough.

That shortcut skips the long way entirely. We also can't simply refuse it: what's expected of us has gone up, because everyone can now get more done with AI.

️ Cognitive debt

Skip the learning once and nothing happens. But each time you take the shortcut, you finish a task without fully understanding how it works or why it was done that way. That gap is cognitive debt.

The debt stays invisible for a while. Then one day you hit a problem AI can't solve, and you have no idea where you are, where to start or where to go. We've all heard of codebases that were thrown away because rebuilding them was easier than understanding them, sometimes even for the AI that wrote them.

⚖️ The fix: a shortcut that balances doing and understanding

The answer isn't to stop using AI. It's to take a slightly longer shortcut, one that balances two things:

Doing: finishing the task, fast.
Understanding: knowing what was done, how, and why (the decisions and trade-offs), and learning to do it yourself.

You're still much faster than on the long way, but you arrive smarter instead of in debt.

You don't need to do this for everything. Set a threshold based on risk: a throwaway script can take the fast path. A decision you'll have to defend, like a security finding, can't.

The good news: AI is also very good at helping you understand. Here's what that looks like on a real task.

The demo: triaging Semgrep findings

The app is a small Express + PostgreSQL order tracker, built in layers like a real app: route → middleware → controller → service → repository. Customers list their orders, download CSV exports and leave comments. Admins see revenue reports.

Demo repo: mohamed-osama-aboelkheir/ai-sast-triage-demo. It's deliberately vulnerable. main is the clean app; reference-output has everything the AI produced in this post.

I ran Semgrep (the free p/default ruleset) and got a handful of findings, all marked as blocking:

SQL injection in orderRepository.js (ORDER BY ${orderBy})
SQL injection in reportRepository.js (FROM ${tableName})
Path traversal in exportService.js
XSS through an unescaped EJS tag in comments.ejs
No CSRF middleware in app.js

As an AppSec engineer, my job is to decide which are real, how severe they are, and which ones are worth an engineer's time. And let's say I don't know this codebase well.

⚡ Approach 1: "just triage it"

The shortest path: open Claude Code, paste the Semgrep output, and ask:

semgrep scan returned the below results, please triage the findings and let me know which are true and which are false positive, and suggest severity and fixes

A couple of minutes later I had a tidy answer:

SQL injection in ORDER BY: true positive, High
Path traversal in /exports: true positive, High
Table name in reportRepository: false positive
<%- %> XSS: false positive
Missing CSRF middleware: false positive

It's a good answer, and it even explains itself. But look at the two SQL injection findings:

// src/repositories/orderRepository.js — flagged
`SELECT id, total, status, created_at FROM orders
 WHERE user_id = $1 AND ($2::text IS NULL OR status = $2)
 ORDER BY ${orderBy}`

// src/repositories/reportRepository.js — flagged
`SELECT count(*)::int AS orders, coalesce(sum(total), 0) AS revenue FROM ${tableName}`

Same library, same pattern: a variable pasted into the SQL text. One is "High", the other is "false positive". If I don't know the codebase, I can't tell whether that's right. I could still copy the verdicts into tickets and move on. That's fast, and it's exactly how cognitive debt builds up. And the moment an engineer pushes back with "this isn't exploitable", I have nothing to say.

So let's take the two SQL injection findings and do it again, with AI helping me understand.

Approach 2: understand, trace, decide, prove

I packaged each step as a Claude Code skill in the appsec-skills plugin, so you can repeat it:

/plugin marketplace add mohamed-osama-aboelkheir/appsec-untangled-resources
/plugin install appsec-skills@appsec-untangled

Each step leaves a file you can read, check and reuse, not chat text you throw away.

1. ️ Understand: read the code like a story

Looking at the two flagged files on their own doesn't tell me much. What's orderRepository.find? Who calls reportRepository.summary? Code is written to be used by people, so the useful context is the story: which user action reaches this line, and what passes through on the way.

Let's start by understanding the context using the /appsec-skills:code-walkthrough skill to explain how the affected backend routes work, and how users interact with them.

The code-walkthrough skill produces two things for each flow:

a sequence diagram: one column per layer, a colour band per phase, for security controls, for untrusted input and ⚠️ for the sink;
a CodeTour file, a VS Code extension that walks you through the code step by step, the way the engineer who wrote it would. Step N in the tour is step N in the diagram.

Here's the story for GET /orders (the full diagram also covers the 401/400/500 exits):

Two steps stand out:

Step 8: the controller validates status against an allowlist, but sort is not checked.
Steps 9–10: sort is renamed orderColumn, then orderBy, on its way down to the query.

The second story, GET /reports/:reportId, is different. It needs an admin, and the controller uses reportId to look up an entry in a config object. Unknown IDs get a 404:

If you were paying attention, you may already see the difference. If not, that's what the next step is for.

2. Trace: source-to-sink

Source-to-sink analysis asks one question: does user input reach the dangerous function, and does anything stop it on the way?

Now using this context, perform the /appsec-skills:source-to-sink analysis for both findings, and share a verdict on whether each is a true or false positive.

The skill walks back from each sink, hop by hop. It draws one chain of code cards per source, with the value in bold on every line and arrows named after what the value is called next.

Finding 1: a red chain (user input) goes from req.query.sort straight to ORDER BY. The only check on the way () covers status, not sort:

Here's that path in the code (controller, service):

// src/controllers/ordersController.js
exports.list = async (req, res) => {
  const { status, sort } = req.query;
  if (status && !ALLOWED_STATUSES.includes(status)) {   // only status is checked
    return res.status(400).json({ error: 'invalid status' });
  }
  const orders = await orderService.search({ status, orderColumn: sort }, req.user);
  res.json(orders);
};

// src/services/orderService.js
exports.search = (filters, user) =>
  orderRepository.find(user.id, filters.status, filters.orderColumn || 'created_at');

$1 and $2 are bound parameters, but column names can't be bound, so ORDER BY ${orderBy} takes whatever the user sends. True positive.

Finding 2: the user's reportId stops ✋ at a lookup into a hard-coded object. The value that actually reaches FROM is a blue chain (config), not user input:

(controller, config)

// src/config/reports.js
module.exports = {
  daily:   { title: 'Orders in the last 24 hours', table: 'orders_daily_summary' },
  monthly: { title: 'Orders this month',           table: 'orders_monthly_summary' },
};

// src/controllers/reportsController.js
const definition = reports[req.params.reportId];   // input picks an entry...
if (!definition) return res.status(404).json({ error: 'unknown report' });
res.json(await reportService.build(definition));   // ...the table name comes from config

The user chooses which trusted value is used. They never supply SQL. False positive. It's still worth a low-priority fix (an allowlist, or Object.hasOwn, so /reports/constructor doesn't return a 500), but it's nowhere near as urgent as finding 1.

The two sinks look identical. Only the trace tells them apart.

I reached the same verdicts as the one-line prompt. The difference is that I can now defend them: I can show an engineer the exact path, the missing check and the fix.

3. Decide: an output template with evidence

That worked for two findings. To do it at scale, I use another trick: an output template. When I triage by hand, I look for the same things every time: the sink, the inputs that reach it, the path between them, the controls on that path, and then a verdict and a severity. So I make the AI fill in exactly those fields.

Now using this context, use /appsec-skills:semgrep-triage to triage both findings.

The semgrep-triage skill runs source-to-sink for every finding, checks each control against a wiki of mitigations and known bypasses, and writes one report. Here are the important parts for finding 1 (abridged):

F1 · SQL injection in ORDER BY via sort · ✅ True positive · High ⬆️

Inputs reaching it: req.query.sort (any logged-in user) reaches the sink unchanged; ⚪ 'created_at' is the constant default.
Controls on the path:
- requireAuth: decides who can send sort, not what it contains.
- Status allowlist: checks status only.
- Parameterised query: binds userId and status; identifiers can't be bound.
- Sort allowlist: none.
Severity: High = Impact High × Likelihood Medium. ORDER BY accepts sub-selects, so the row order becomes a yes/no oracle over the whole database, including the admin's API token. Any logged-in user can reach it.
Why Semgrep says less: the rule's MEDIUM/LOW is generic. It can't see that orderBy comes straight from the query string.
Suggested fix: an allowlist of sort columns, right next to the existing status check:

const SORT_COLUMNS = new Map([['total', 'total'], ['status', 'status'], ['created_at', 'created_at']]);

if (sort !== undefined && !SORT_COLUMNS.has(sort)) {
  return res.status(400).json({ error: 'invalid sort' });
}
const orders = await orderService.search({ status, orderColumn: SORT_COLUMNS.get(sort) }, req.user);

The part I care about most is Evidence (Manual Reproduction): the steps to reach the same conclusion myself, without trusting the AI.

Read the sink: src/repositories/orderRepository.js:7-11.
Find who calls it: grep -rn "orderRepository.find" src → orderService.js:4.
Find where orderColumn is set: grep -rn "orderColumn" src → ordersController.js:11, orderColumn: sort.
Find where sort comes from: ordersController.js:6, req.query. The only check (:7) is on status.
Find who can send it: routes/orders.js:5, requireAuth only.
Confirm locally: ?sort=total → 200 sorted by total; ?sort=price → 500, and the server log shows column "price" does not exist. The value reached the SQL text.

And for the false positive, the report doesn't just dismiss it. It says when it would become real, and what to do with the rule:

Would become a true positive if: tableName were ever taken from the request.
Rule decision: keep the rule enabled (it found a real bug in F1) and suppress this one instance with a comment that points to the triage.

The template does two things. It makes the AI follow the steps I would follow. (Without it, a model will often give a verdict, then admit "actually I didn't check X" when you push.) And it teaches me the pattern every time I read a report. If you'd like to test yourself first, run it with --learn: you give your own verdict, then compare.

4. Prove: an experiment instead of trust

Now the XSS finding. The template prints each comment unescaped:

<!-- src/views/comments.ejs:18 -->
<div><%- comment.html %></div>

<%- doesn't escape HTML, so Semgrep flags it. The triage traced user input from POST /comments to this line, and found one control on the way (source):

// src/utils/markdown.js
exports.render = (text) => DOMPurify.sanitize(marked.parse(text));

Verdict: false positive, because DOMPurify removes the payload. But say I've never used DOMPurify. Why is it enough? I could read the docs. Or I could ask AI to build me a small experiment I can run myself:

Create an /appsec-skills:security-experiment to explain how DOMPurify sanitize mitigates XSS with a simple example.

The security-experiment skill writes a Jupyter notebook (a Deno kernel, with the app's real library versions and its real template). It sends one classic payload through the app's steps, one cell per step, first without DOMPurify and then with it:

── Without DOMPurify ──
▶ marked.parse(text)
  <p>Package arrived damaged <img src="x" onerror="alert('XSS')"></p>
  ⚠️  dangerous: onerror="alert('XSS')"

── With DOMPurify ──
▶ DOMPurify.sanitize(html)
  <p>Package arrived damaged <img src="x"></p>
  ✅ nothing dangerous left

▶ what DOMPurify removed
  ✂️  onerror="alert('XSS')" from <img>: event handlers are not on its allowlist

The notebook ends with why that's enough (it runs on every render, after marked, as the last step before <%-) and what would break it (removing it, moving it to input only, changing the HTML after sanitising, or an outdated version with a known bypass). I saw the control work. I didn't just take its word for it.

✅ Same verdicts, very different engineer

After both approaches:

Approach 1 gave me verdicts in two minutes. I couldn't explain them, and the next similar finding would take just as long, because I learned nothing.
Approach 2 gave me the same verdicts with a few short prompts, plus:
- diagrams and tours of how the feature actually works;
- a trace showing exactly why two identical-looking findings differ;
- a report with reproduction steps and a tested fix I can hand to the engineer;
- an experiment that taught me how DOMPurify works.

I can now go to the engineering team with a priority I can stand behind: fix the ORDER BY injection now; the table-name pattern is a low-priority hardening task.

Takeaway

None of these techniques are specific to security. Wherever you use AI, you can ask it to:

Visualise: turn code into a diagram and a guided tour, so you read it as a story;
Trace: follow one value through the layers instead of trusting a summary;
Template: make it fill in the fields you would check yourself, with evidence;
Experiment: build something small you can run, to see the claim hold;
Quiz you: give your own answer first, then compare (--learn).

AI is a powerful tool, and using it does make you more efficient. Just keep an eye on the cognitive debt. Balance doing and understanding, so you're faster now and not stuck later.

Try it yourself

Demo app (deliberately vulnerable) and every AI output from this post: ai-sast-triage-demo
The skills: appsec-skills (code-walkthrough, source-to-sink, semgrep-triage, security-experiment). PRs are welcome.
More on YouTube: AppSec Untangled

How do you use AI to learn and not just to finish tasks? Tell me in the comments. I'd love to add more ideas to the skills.

The Plausible PR: I Gave 4 LLMs 10 Sneaky Refactors, and They All Missed the Same Bug

Wed, 30 Sep 2026 10:41:40 +0000

What I Benchmarked

**
I keep seeing posts about using AI to review pull requests before they get merged. That made me want to test one specific thing: can an LLM catch a security bug when nobody tells it to look for one?

So I built a benchmark called "Plausible PR." It has 10 pull request diffs. Each one is written to look like a harmless cleanup: collapsing an if-statement, swapping a comparison, "simplifying" a query. Every single diff actually removes something that was protecting the app: a permission check, a rate limit, a constant-time comparison, an input boundary check.

The prompt is always the same: "Is this PR safe to merge?" I never tell the model to look for security issues. I just want to know if it notices on its own, the way a careful human reviewer would.

Models Tested

**
I ran the benchmark against four models:

Claude Sonnet 5 (Anthropic)
GPT-5.5 (OpenAI)
Gemini 3.7 Flash (Google)
DeepSeek-R1 (DeepSeek)

I picked one model from each major lab, plus an open-weight model, so the comparison covers the range people actually choose between when they wire an LLM into a review workflow.

Findings
Here is the full board, pass or fail per task per model:

Claude Sonnet 5 came out on top with 9/10. GPT-5.5 trailed at 6/10.

The result that surprised me most is task 2. It is a one-line change: a token check switches from comparing bytes to comparing a plain string with secrets.compare_digest. That function throws a TypeError on non-ASCII text instead of returning False. So a malformed login attempt no longer gets a clean 401, it crashes the request instead. All four models, including the one that scored 9/10 on everything else, called this a safe simplification and approved it.

The pattern I noticed: models are good at catching bugs that have a keyword to react to. "SQL" and string interpolation together set off an obvious alarm, so every model caught the SQL injection (task 4) and the path traversal (task 9). But bugs that only show up when you trace what happens to a slightly unusual input, like a malformed header or a non-ASCII string, get waved through even by the strongest model. Nothing about the diff "looks dangerous." It just quietly changes what happens on an edge case nobody wrote a test for.

If I ran this again, I would add a second round: give the model the same crash bug, but this time ask "does this handle all input types correctly," and see if a more targeted prompt catches what the open-ended "is this safe to merge" prompt misses. That would tell me whether this is a knowledge gap or a hint-dependence problem.

My Benchmark
Full benchmark on Kaggle:

https://www.kaggle.com/benchmarks/kudzaimurimi/plausible-pr-security-bugs-hidden-in-clean-refact

Each task includes the full diff, the model's response, and the judge criteria used to score it, so you can see exactly why something passed or failed.

OWASP Founder Jeff Williams: Stop Studying the Robot's Brain. Start Controlling Its Body.

Thu, 17 Sep 2026 21:00:26 +0000

Jeff Williams, founder of OWASP and founder and CTO of Contrast Security, has spent the last several years watching the security industry pour its attention into one question: can you jailbreak the model, trick it, make it say something dangerous. He thinks that's increasingly the wrong place to be looking. "Once you give the brain a body, there's a much more consequential question: what can the robot actually do?" he said.

The "body," in Williams's framing, is what's increasingly being called an agent harness, the tools, memory, permissions, orchestration, and runtime infrastructure that surrounds a model and turns raw intelligence into something capable of taking real-world action. As agents move from answering questions to executing code, touching databases, and sending money, Williams argues the harness has quietly become at least as important to an agent's actual risk profile as the model powering it, maybe more so.

The same brain, two completely different agents

Williams's central metaphor is worth sitting with because it reframes how you'd even evaluate an agent in the first place. "Imagine putting the same robot brain into two completely different bodies," he said. "Give one a camera and a speaker. Give the other access to your email, GitHub, production systems, corporate databases, and a credit card. They're powered by exactly the same intelligence, but they are radically different agents."

That has a direct, practical consequence for anyone deploying agents today: "Evaluating an agent based solely on its model is increasingly meaningless. You have to know what body we've attached to the brain." A vendor's model benchmark scores tell you almost nothing about what that model can actually do once it's wired into a real system with real credentials.

What belongs in the harness, and why the brain shouldn't set its own rules

Williams draws a clean line around what belongs outside the model itself: context and data (the agent's senses), memory (retained experience), tools (its hands), orchestration (its nervous system), and identity and permissions, which determine which doors it can open. That last category gets the most emphatic treatment in his answers. "I don't want the robot's brain deciding its own permissions. Every attempt to do this has been circumvented," he said. "The rules governing what the robot can do should live outside the brain."

That's a direct rebuttal to any architecture that asks a model to police its own behavior through instructions or system prompts alone. Williams's position is that permission boundaries need to be enforced by something outside the reasoning process entirely, not negotiated with it.

Controlling behavior versus controlling action

Here's the distinction Williams thinks the industry keeps missing: you may never be able to fully control what a model "thinks," but you can control what its body is capable of doing regardless. "We can determine whether it can access a database, execute code, send an email, deploy software, or transfer money. We can require approval for sensitive actions. And we can monitor what it actually does," he said. "That may ultimately be a much stronger security boundary than trying to perfectly control a probabilistic model."

The physical analogy he uses is blunt: "If I have a robot standing next to me, I'd rather physically prevent it from opening the vault than give it an instruction saying, 'Please never open the vault.'"

The unsolved problem hiding inside that answer

Williams isn't claiming this is a solved problem, and that honesty is worth preserving rather than smoothing over. Simple allow/deny permissions aren't sufficient on their own, he said, because "we don't know in advance exactly what capabilities a robot needs to accomplish the goal we assigned. If we over-restrict our robot, we lose exactly the creative capability that makes it so powerful." The real question, in his words, is "can we figure out how to keep the robot from doing things we don't want without sacrificing the ability to accomplish cool and interesting things? It's certainly a runtime control problem, but we haven't solved it yet."

Why the harness is also a new attack surface

The same infrastructure that makes an agent useful also makes it exploitable in new ways. "The harness is just software, and it creates an enormous new attack surface," Williams said. An attacker doesn't need to break the model at all; poisoning any input the model sees can be enough to manipulate what the agent does next; manipulating what it perceives, poisoning its memory, tricking it into misusing a tool, exploiting excessive permissions, stealing its credentials, or chaining several individually reasonable actions into something dangerous overall.

That reframes what the actual unit of security risk should be. "The important security unit becomes the agent using a capability against a particular resource in a particular context, not simply the prompt or the model output," he said. A single action can look completely reasonable in isolation and still be part of a dangerous chain.

Where this is all heading

Williams doesn't think the answer is picking one layer to defend. "We should continue making the brain safer. But we should assume that sometimes the brain will misunderstand something, hallucinate, get manipulated, or simply make a bad decision," he said. His framing for what that means in practice: limits built into the body and nervous system, monitoring of actual behavior, controlled access to dangerous capabilities, and real-time intervention mechanisms when something goes wrong.

The stakes of getting this wrong scale with what the agent is actually connected to. "A hallucination from a chatbot might produce a bad answer," Williams said. "A hallucination from an agent with production credentials can produce an outage." As agents pick up more autonomy and more access, that gap between "bad answer" and "real damage" is exactly the space the harness is supposed to close.

F5's AI WAF Caught 15 Zero-Days Before a Human Ever Saw Them

Thu, 03 Sep 2026 12:00:00 +0000

F5's Jimmy White, the company's CTO AI Security, put a number on the problem last week: mean time to exploit for a new vulnerability is now under seven days. That's not vendor time — that's the window between disclosure and someone weaponizing it. If your patch cycle runs longer than that, and for most engineering teams it does, you're exposed by default.

F5 just shipped an answer to that gap: an AI-powered Web Application Firewall running on Distributed Cloud that has autonomously detected 15 zero-day attacks and cut false positives from about 18% to about 1%. I talked with White about how it actually works, and the answer is more interesting than "we added AI to a WAF."

Why a custom model instead of a fine-tuned LLM

F5 built a proprietary neural network rather than fine-tuning a foundation model, and White says the decision came down to where the model has to live. "It's around speed and it's on the data path," he told me. A WAF inspects every request in real time. There's no room for the latency a general-purpose LLM would add, and F5 already had the volume of security traffic needed to train something purpose-built and fast.

The model doesn't lean on any single signal. It combines signatures, malicious-user detection, anomaly detection, and behavioral zero-day patterns — the same categories WAFs have always used, but correlated instead of evaluated in isolation. That correlation is what took false positives from 18% down to 1%. White's analogy: a hammer near a nail looks fine. The same hammer near a window looks like a threat. Context, not any one rule, makes the call.

How the "patch" actually happens

Here's the part developers will want to understand: F5's virtual patching isn't a rule someone writes after a CVE drops. When the neural net flags traffic as novel and malicious, that pattern gets treated as known-bad from that moment forward — no re-scanning, no waiting on a signature update. "It's novel the first time," White said. "It's not going to be novel from then on." That's the patch: a real-time classification that turns a zero-day into ordinary traffic filtering within the same session it was discovered.

It also explains the variant problem. Attackers typically don't stop at one exploit. They generate hundreds of small variations to see what gets through. Because the model has already learned the underlying pattern, White says it catches the variants too, not just the original.

None of this runs fully unsupervised end to end. Model upgrades go through human review before release, and F5 tests new versions internally — "dog fooding," in White's words — before pushing them to production.

The stack matters more than the model

White was clear that AI WAF isn't meant to stand alone. F5 pairs it with DDoS protection and bot defense specifically so a traffic spike, like a DDoS event or a scraper storm, gets filtered out before it ever reaches the WAF's training pipeline. Skip that step and a bad batch of traffic could skew what the model learns as normal. It's a detail worth remembering if you're evaluating any AI-driven security tool: ask what protects the training data, not just what the model does with clean data.

The results are validated by SecureIQLab, an independent testing firm F5 has no ability to influence. "The only guarantee we have is our protections have never seen the attacks before," White said. That test produced a 100% score against the OWASP WAF and API Top 10 lists — numbers worth taking with the usual skepticism toward vendor-selected benchmarks, but the blind-test structure is at least a real attempt to earn that skepticism's benefit of the doubt.

What this doesn't change

AI WAF currently runs on Distributed Cloud only. F5 plans to bring it to BIG-IP, NGINX Plus, and NGINX Open Source over the next couple of quarters, and White describes the upgrade path as simple: no SDK, no API integration, just an update that adds the capability to an existing WAF deployment.

What it doesn't do is give engineering teams permission to slow down. I asked White directly whether this changes how a developer should think about patch cadence. His answer was blunt: "I wish you could relax." The WAF buys time in the gap between disclosure and a real fix — White offered one to six days as a rough example of that window — but it's not a substitute for shipping the fix. "It'd be very dangerous for me to say you can kind of rest on your laurels," he said. "In this era, it's super important to find and fix as quickly as possible."

That's the honest read on where AI-assisted security tools stand right now. They're buying real time in a race that's gotten faster on both sides. They're not ending the race.

Cycode's AI Scanner Found 38 Bugs in MLflow. The Press Release Only Mentioned One.

Wed, 02 Sep 2026 14:41:12 +0000

Every AI security vendor ships a benchmark chart these days. Most of them don't survive a second phone call.

On September 1, Cycode launched Agentic Code Scanning, a fourth layer that sits on top of its existing rule-based scanner and decides, code path by code path, whether a deterministic rule or a reasoning model should do the looking. The pitch lands at a useful moment: Lovable just raised $400 million at a $13.3 billion valuation, doubling in eight months, and AI-generated code is no longer a side project. It's shipping into production at companies that can least afford a bad merge.

Cycode's headline number: it ran the new engine against six real, published CVEs and caught all six, including two authorization flaws — a broken access control bug in gitea (CVE-2025-68941) and a middleware bypass in Next.js (CVE-2025-29927) — that no rule-based scanner in the test could catch, because there's no bad pattern to match. A missing permission check doesn't look like anything. Cycode's own deterministic scanner caught three of the six. Semgrep and CodeQL, tested separately, caught zero.

I asked Amir Kazemi, Cycode's senior director of product marketing, how the company picked its ten benchmark repositories — six pinned to CVEs, four deliberately vulnerable apps used as answer keys. He didn't have the specifics. "That's a question for our CTO," he said, and offered to follow up. That's not unusual on a launch call. It's also exactly the kind of question that decides whether a benchmark means anything.

Ronen Slavin, Cycode's CTO and co-founder, answered in writing a day later, and the detail went well past what made it into the press release.

The methodology, as he described it: the six CVE repos were the development set, used openly to build the engine. The four answer-key apps — vAPI, crAPI, DV RESTaurant, and Juice Shop, all existing open-source projects, not synthetic builds — were held out and untouched until testing. Before any fix went in, Slavin's team wrote down constraints in advance: no code change could reference a specific benchmark file, CVE ID, or line number, and any fix that moved the needle on the development set had to also hold up on the held-out apps. A hit only counted if it matched the actual mechanism behind the CVE, not just the file it lived in.

That structure exists to answer the obvious challenge: how do you know a reasoning model found the bug, instead of recalling it from a public CVE database sitting in its training data? Slavin's answer is specific rather than reassuring. The scanner is never told which CVE it's hunting, the test repos are pinned commits with no changelog or advisory text attached, and the findings are line-anchored data-flow traces written in the code's own variable names, not summaries that read like an advisory. On Jellyfin, he said, the model traced the vulnerable data flow across six function calls from an HTTP query parameter to the FFmpeg argument string, entering through a different controller than the one named in the public advisory. A model quoting a memorized answer doesn't take a six-hop detour to get there.

The press release's cleanest number undersold what the tool actually produced. It said a rule fired 573 times on mlflow, two hits landed in the CVE file, and Agentic Code Scanning returned "one validated, root-caused finding." Slavin's fuller account: on that same repository, the engine generated 87 raw candidate findings and published 38, each deduplicated and root-caused, including extra bugs the CVE never asked about — a symlink traversal in the artifact store, a zip-slip, and a template injection among them. The rule that fired 573 times, he clarified, belongs to Bearer — the same rule engine that already underlies Cycode's own deterministic scanner, which is a more interesting detail than the press release let on. The honest comparison, he argued, isn't 573 versus one. It's somewhere between 173 and 701 unranked hits per repository, depending on the repo, against 38 findings on mlflow that a developer could actually act on.

The single-run limitation in the published benchmark is real, and Slavin didn't dodge it. He called the published result "an existence proof, not a rate." Since the tested engine version shipped, gitea's authorization catch has reproduced in nine of nine repeat runs, and the full six-for-six result has held on a second model. Where a catch was inconsistent — Jellyfin missed on some runs until the team added a specific lead pointing to what reaches the vulnerable sink — Slavin says they found the cause and fixed it rather than rerunning until it worked. Cycode says it's now publishing catch rates across repeated runs going forward, not single screenshots, and has already extended its CVE corpus to 20 languages and 29 verified vulnerabilities.

None of this turns a vendor benchmark into independent research. It's still Cycode grading its own homework, and reasonable people will still want a third party to rerun it — something Cycode says is now possible with the corpus and configs it's publishing alongside the launch. But the gap between what showed up in the press release and what showed up under a direct follow-up is the real story here. As agentic security tools multiply — and Kazemi's own framing of a linear SDLC turning into a faster, circular ADLC suggests they will keep multiplying — the benchmark chart on the landing page is worth less than a vendor's willingness to answer the second question. Ask it before you buy.

Developer Weekly Briefing — August 28, 2026

Fri, 28 Aug 2026 14:29:15 +0000

A quieter week after the Black Hat stretch, but the five pieces that came out of it are worth your time. All five circle the same territory: what AI can and can't actually do in security, and who ends up owning the outcome when it falls short.

Triaging AI scanner output costs 400x more than running the scan

Here's the number from Contrast Security's AppSec Overflow 2026 report that should reframe every "AI will solve your security backlog" pitch you hear this year: scanning a 2-million-line codebase with an AI-powered tool costs roughly $315 in tokens. Triaging what that scan finds costs $128,000. The scanning was never the expensive part.

The report draws on runtime telemetry from hundreds of thousands of production applications — not theoretical exposure, but what's actually being reached and exploited in live systems. A few data points worth internalizing:

The average application absorbs 11,382 attacks a month. 87.8% are automated probes — noise. The number that actually matters is the 0.4%, an average of 42 viable attacks per month per application, where Contrast confirmed the exploit reached and triggered real vulnerable code. Teams are closing 3.4 vulnerabilities per application per month against an average of 22 rated high or critical. Mean time to remediate a critical vulnerability: 92 days. Mean time to exploit: effectively same-day for a growing share of CVEs.

The AI scanner reliability findings are the most useful part for teams evaluating these tools. Three different AI scanners analyzing the identical codebase agreed on only 5% of findings. A single scanner rerun three times against unchanged code reproduced just 17% of its own prior results. That's not a calibration issue — it's a fundamental reliability problem for any team trying to build a repeatable process around these tools.

One claim worth a caveat: the report opens by citing Anthropic's Claude Mythos model reportedly discovering thousands of previously unknown zero-day vulnerabilities in production testing. Contrast's own report flags the limitation — Anthropic hasn't disclosed the time, accuracy, and human effort behind the analysis. Treat that specific claim as unverified, even as the broader trend it illustrates is real.

Cisco's Amy Chang: a model's "passport" doesn't tell you where it actually came from

Amy Chang, EVP and Chief Product Officer at Cisco, makes a point that gets at a real gap in how most organizations think about AI supply chain risk: a model card or declared provenance tells you what a vendor says about a model, not what actually went into it. The training data, the fine-tuning process, the intermediate checkpoints — none of that is independently verifiable from the outside. As AI models become infrastructure, the question of what's actually in them starts to matter the way software bill of materials questions started to matter for open-source packages. The tooling to answer it doesn't really exist yet.

AI can find your vulnerabilities. It still can't own what happens next.

The conversation with GuidePoint Security's Victor Wieczorek covers the same territory as several Black Hat sessions but with more precision. AI is genuinely good at finding needles in haystacks — that's not the bottleneck. The bottleneck is everything downstream: understanding what a finding means in context, deciding what to do about it, and owning the professional judgment that a client can actually act on. No model carries that obligation. The Glasswing stat that runs through this piece is worth remembering: fewer than 1% of the vulnerabilities AI discovered in that program ever got patched. Finding the bug was never the hard part.

$360,000 a petabyte and 105 days to get out: Microsoft's new math for university storage

Microsoft capped Education tenant storage this year and turned on overage pricing worth roughly $360,000 per petabyte per year once quotas are exceeded. Universities holding two or three petabytes — common at large research institutions — are looking at bills in the hundreds of thousands to over a million dollars annually for storage they never budgeted for. The exit problem is equally sharp: Microsoft throttles data egress at 400GB per hour, tenant-wide, meaning moving one petabyte out takes approximately 105 days. For institutions just realizing the size of the problem, the December 2026 renewal deadline is already close.

Arcitecta's Mediaflux Connect 365 is the platform announced around this story — the piece covers both the cost math and the data management approach behind moving out intelligently rather than just fast.

The bug that's been breaking software for 40 years is now breaking your AI agents too

Integer overflow — the category of bug where a value exceeds what a data type can hold and wraps around to an unexpected result — has been causing security vulnerabilities since the 1980s. It's behind buffer overflows, memory corruption, and a long list of CVEs across decades of software. The same class of bug now shows up in AI agent tool calls and API interactions, where numeric inputs passed to or from an agent can overflow in ways the agent doesn't detect or handle. The post makes the case that this isn't a new threat category — it's a familiar one arriving in a new execution context, and most teams building agentic systems aren't thinking about it yet.

The through-line this week: AI is genuinely expanding what's possible in security tooling, and the costs and failure modes that come with it are starting to get documented with real numbers. $315 to scan, $128,000 to triage. 5% agreement across three scanners. Fewer than 1% of discovered vulnerabilities patched. Those aren't arguments against using AI in security — they're arguments for being precise about what it's actually doing and who owns the judgment call when it's done.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

Contrast Security: Triaging AI Scanner Output Costs 400x More Than Running the Scan

Thu, 27 Aug 2026 13:15:00 +0000

Here's a number worth sitting with: scanning a 2-million-line codebase with an AI-powered tool costs roughly $315 in tokens. Triaging what that scan finds costs $128,000. That 400x gap, buried in Contrast Security's new AppSec Overflow 2026 report, is a sharper indictment of "AI will solve your security backlog" than any headline vulnerability count. The scanning was never the expensive part. Making sense of what it found is.

Contrast's report draws on runtime telemetry from inside hundreds of thousands of production applications and APIs, giving it a vantage point most vendor research doesn't have: not what's theoretically vulnerable in a codebase, but what's actually being reached and exploited in live production. The headline framing is stark. "AppSec math is broken, and in 2026, AI is a massive contributing factor," the report states, and the numbers back that up from multiple directions at once.

The attack volume is relentless, but mostly noise

The average monitored application absorbs 11,382 attacks a month, roughly one every four minutes. That number sounds alarming until you break it down: 87.8% are automated probes, low-stakes reconnaissance that maps attack surfaces without doing harm. Another 11.9% are suspicious but unconfirmed. The number that actually matters is the remaining 0.4%, an average of 42 viable attacks per month per application, meaning Contrast confirmed the exploit reached and triggered real vulnerable code. No false positives in that category; runtime observation proves activation, not just exposure.

Untrusted deserialization leads the viable attack data at 27.5%, followed by path traversal at 20.1% and method tampering at 13.4%. SQL injection, despite being one of the most well-understood vulnerability classes in software, still shows up in the top five attack techniques across every industry vertical the report tracked, a reminder that "well documented" and "actually fixed" are very different things.

Why the find-and-fix model is structurally broken, not just slow

The average application carries 106 vulnerability findings in custom code, and while roughly 60% of those are informational noise, an average of 22 are rated high or critical. Teams are closing just 3.4 vulnerabilities per application per month, and the mean time to remediate a critical vulnerability sits at 92 days. Third-party code fares no better: 54% of the CVE instances Contrast observed in production are from vulnerabilities disclosed more than a year ago.

That gap matters more than it used to because the other side of the equation has collapsed. Third-party research the report cites, aggregated by Zero Day Clock across more than 83,000 CVEs, shows mean time-to-exploit dropping from 2.3 years in 2018 to effectively same-day in 2026. Independent data from VulnCheck backs the trend, finding 29% of exploited CVEs in 2025 were weaponized on or before the day the CVE was published. A 92-day patch cycle against a same-day exploitation window isn't a performance problem. It's a structural mismatch that faster patching alone can't close.

The AI scanning findings, and one claim worth a caveat

The report's most useful contribution isn't the vulnerability count, it's the honest accounting of what AI scanning tools actually deliver today. Beyond the $315-versus-$128,000 triage-cost gap, Contrast found that three different AI scanners analyzing the identical codebase agreed on only 5% of findings. A single scanner rerun three times against unchanged code reproduced just 17% of its own prior results. That's not a minor calibration issue; it's a fundamental reliability problem for any team trying to build a repeatable process around these tools. Contrast's own framing is blunt: "For now, it's making the hole a lot deeper."

Worth flagging separately: the report opens with a claim about Anthropic's Claude Mythos model reportedly discovering thousands of previously unknown zero-day vulnerabilities in production testing, including a flaw in OpenBSD that had survived 27 years of human review. This has circulated in several industry newsletters, but Contrast's own report is careful to caveat it: "Anthropic has not disclosed the time, accuracy and human effort that was required for their analysis, making it difficult for security leaders to make real risk assessments today." Treat the underlying capability claim as unverified, even as the broader trend it's illustrating, AI compressing vulnerability discovery timelines, is well supported by the report's own runtime data.

Why CVSS and EPSS alone will steer you wrong

The report's prioritization section is the most practically useful part for a working developer or architect. Generic CVSS base scores tend to inflate perceived risk because most organizations never layer in the local context the scoring system was actually designed to incorporate. EPSS, which predicts 30-day exploitation probability, correlates strongly with real-world exploitation, 85% of CVEs with an EPSS score above 94% are on CISA's Known Exploited Vulnerabilities list, but it isn't complete either. The report cites two confirmed-exploited CVEs with EPSS scores of 22.2% and 0.88% respectively, low enough that a pure EPSS-driven process would have deprioritized both.

Contrast's answer is reachability and exploitability analysis: does the vulnerable function actually execute, does untrusted data actually reach it, and is the application configured in a way that makes exploitation possible. That's a meaningfully different, more precise filter than severity scores alone, though it's also, unsurprisingly, exactly what Contrast's own runtime platform is built to provide. Worth reading that recommendation with the appropriate grain of salt given who's making it, even where the underlying logic holds up.

What this actually means for the average team

Strip away the vendor framing and the practical takeaway is straightforward: attack surface and vulnerability volume are both growing faster than patch cycles can absorb, generic severity scores aren't precise enough to prioritize effectively at that scale, and AI scanning tools, at least in their current form, are adding inconsistent findings to the pile faster than they're helping teams work through it. The report's own conclusion lands on runtime visibility, actually knowing which vulnerabilities are reachable and being actively targeted, as the lever that matters most. That's a reasonable read of the data, even from a company that sells exactly that capability.

Manually Breaking Authentication — A Full Walkthrough (CWE-307, CWE-330, CWE-640

Wed, 26 Aug 2026 06:18:14 +0000

⚠️ Educational / authorized testing only. Everything below targets a local, deliberately vulnerable training application, not a live system. Never run these techniques against anything you don't own or don't have explicit written authorization to test.

Automated scanners are great at pattern-matching known vulnerability classes. They're much weaker at authentication flaws that look completely legitimate at the HTTP level — a 200, a 401, a token — and only become a bug once you understand how the value was generated. This walkthrough is a fully manual assessment of three such bugs in a deliberately vulnerable login system, captured start to finish with nothing but a proxy-backed browser and a network tab.

The bugs

#	Bug	CWE	OWASP
1	`POST /login` has no rate limit, delay, or lockout	CWE-307	A07:2021 – Identification and Authentication Failures
2	Session tokens are sequential integers, not random	CWE-330	A07:2021
3	Password-reset token is `md5(username)` — deterministic, not random or single-use	CWE-640	A07:2021

Phase 1 — No brute-force protection

Three wrong passwords for admin, back to back, then the real one. All four POST /login requests return instantly — no 429, no CAPTCHA, no increasing delay. Filtering the network tab down to login shows the whole sequence sitting there in plain sight: nothing on the server side ever notices the repetition.

That's the entire proof for CWE-307. A real attacker isn't limited to four guesses — they're limited by whatever rate their network connection allows, because the server places no limit of its own.

Phase 2 — Predictable session tokens

The login endpoint hands out tokens from a shared, incrementing counter — regardless of which account is logging in. alice gets 1001. bob gets 1002. That's already suspicious, but the real proof of impact is this: clear your cookies, open a private window, and request /whoami?session=1001 with zero credentials. The server hands back alice's full identity, because "knowing a number" and "being alice" are treated as equivalent.

Phase 3 — A reset token that isn't a secret

/reset-token?username=alice returns a 32-character hex string that looks random — until you request it again and get the exact same value back. It's not a secret; it's md5("alice"), a pure function of public data. Anyone who knows a username can compute their "reset token" offline, with no server interaction and no account access at all.

From evidence to finding

Each bug was routed from the network capture into a manual finding — evidence field populated with the actual request/response pairs, CWE and OWASP mapping attached, and a concrete fix:

Finding A (Medium) — add per-account and per-IP throttling with exponential backoff or lockout, plus a CAPTCHA after repeated failures.
Finding B (High) — issue tokens from a cryptographically secure random source (128+ bits), never a counter.
Finding C (High) — generate a random, single-use, time-limited reset token, stored server-side and delivered only to the account's verified contact method.

Takeaway

None of this required exploit tooling — it required patience, a network tab, and the discipline to capture evidence before writing a single conclusion. Scanners are excellent at known-signature bugs; deterministic secrets and predictable state are exactly the class of finding that still needs a human reading raw traffic.

What's the last "boring" auth bug your team caught that a scanner missed? Curious to hear how others are covering this gap.

Try it yourself → https://github.com/sendwavehub/scan-target-demo-apps
Windows Store https://apps.microsoft.com/detail/9pj0j7bk1m27?hl=en-US
Web Site https://Sendwavehub.tech/en/apps/ai-security-studio-4

Manually Proving and Documenting an IDOR (CWE-639) — A Full Walkthrough

Mon, 24 Aug 2026 13:07:58 +0000

Most IDOR write-ups stop at "change the ID in the URL and you get someone else's data."
That's the easy part. The part that actually matters — proving it rigorously, ruling out
the boring explanation, and turning it into a report someone can act on — usually gets
skipped.

I recorded a full walkthrough doing exactly that, end to end, against a deliberately
vulnerable local training target.

{% youtube 8RlBRBQBUAw %}

The bug

A simple invoice endpoint, GET /invoices/:id. It checks that someone is logged in
(401 if not), but never checks that the logged-in identity actually owns the invoice
it's returning:

invoices.find(inv => inv.id === Number(req.params.id))
// no invoice.owner === session.user check
Log in as any user, change the number in the URL, read anyone's invoice. Classic
CWE-639 — Authorization Bypass Through User-Controlled Key, and it maps directly to:

OWASP A01:2021 — Broken Access Control
API1:2023 — Broken Object Level Authorization (BOLA)
What the walkthrough actually covers
The video isn't just "look, it's broken" — it's the full evidence chain a real assessment
needs:

TimestampPhase
0:00Capture two separate identities (alice, bob)
1:26:19Prove cross-owner access live, in-browser
2:06:26Pull raw request/response evidence from the network tab
2:52:04Run a negative control — unauthenticated request, confirm 401
4:08:06Confirm independently with an automated IDOR probe
6:12:03Create a structured finding (CWE/OWASP/API mapping + evidence)
8:12:07Structure the evidence for review
10:29:00Export a report
The negative control is the step people skip most often, and it's the one that separates
"broken access control" from "there's just no auth at all" — an important distinction if
you're writing this up for a real triager.

Why the control matters
Without it, you've only shown that an authenticated user can read someone else's data —
you haven't ruled out the (much less interesting) possibility that the endpoint has no
auth check whatsoever. Hitting the same endpoint with zero session and getting a clean
401 proves the app does enforce authentication — it just never enforces ownership.
That's the difference between a one-line "missing auth" bug and a systemic
authorization-model gap.

Fix
Load the object, then check ownership before returning it:


const invoice = invoices.find(inv => inv.id === Number(req.params.id));
if (!invoice || invoice.owner !== session.user) {
  return res.status(404).end(); // or 403 — avoid leaking existence via 401 vs 403
}
Every object access needs to be authorized, not just authenticated — that's the whole bug
in one sentence.

All testing shown is against a local, self-hosted, intentionally vulnerable training app —
offline, no unauthorized access. If you're learning web app security, bug bounty hunting,
or just want to see what "proving" a vuln looks like beyond a screenshot, the full video
is above.

Try it yourself → [https://github.com/sendwavehub/scan-target-demo-apps][1]
Windows Store [https://apps.microsoft.com/detail/9pj0j7bk1m27?hl=en-US][2]
Web Site [https://Sendwavehub.tech/en/apps/ai-security-studio-4][3]


  [1]: https://github.com/sendwavehub/scan-target-demo-apps
  [2]: https://apps.microsoft.com/detail/9pj0j7bk1m27?hl=en-US
  [3]: https://Sendwavehub.tech/en/apps/ai-security-studio-4

Harness GM Rahul Sood: Most "AI Remediation" Claims Don't Actually Work. Here's What Does.

Wed, 19 Aug 2026 15:00:00 +0000

Application security has operated on human timelines for as long as it's existed: a scanner flags something, a ticket gets filed, developers and security argue over priority, and a fix ships weeks or months later, if it ships at all. Rahul Sood, GM of Application Security at Harness, points to Log4j as the cautionary tale everyone in the industry already knows by heart. "It was not uncommon for companies to say it took us almost one year to get rid of it," he said. "Right now, that does not work when attackers have AI that can identify vulnerabilities in your code, even if you thought your code was safe."

Harness is launching a set of AI-driven application security capabilities this week aimed at collapsing that timeline. The stakes are concrete: attackers are now going from disclosure to first exploit in as little as six hours, while the average vulnerability still takes more than 50 days to fix. Sood breaks into three required shifts: defenders need to actually use AI to find weaknesses in their own code, the window between discovering a vulnerability and fixing it needs to compress from months to hours, and organizations need to accept that not every fix will land before an attacker finds a way in, which means building a containment strategy alongside the fix itself.

Scanning with frontier models is real, and also too slow to run daily

Sood doesn't dispute that frontier models can scan code effectively. The problem is cost and speed. He cited a bank going through Anthropic's Glasswing program that took three months to scan its entire codebase using an LLM — and Glasswing partners broadly have surfaced roughly 10 times more vulnerabilities using LLM-based scanning than traditional tools find, a wave of visibility that just becomes a bigger backlog without a faster way to act. "The cost is it takes a lot of tokens. The output is not deterministic, and it's not easy for you to go and triage these vulnerabilities," he said.

Harness's answer is two separate capabilities rather than one. The first, LLM Scan Orchestration, is a native integration between its CI/CD security tooling and LLM-based scanning, supporting both Claude and OpenAI's Codex, so findings get triaged, deduplicated, and normalized into a developer's existing workflow instead of arriving as an unstructured wall of output. The second, AI SAST, layers AI reasoning on top of traditional static analysis, aiming to catch what conventional scanners miss (Sood pointed to business logic attacks as an example) while using that reasoning to cut false positives and explain why a finding matters. From there, a Triage Agent automatically prioritizes what's actually exploitable so teams can focus on real risk, and a Remediation Agent writes and validates a fix for a prioritized finding, opening a pull request for a developer to review and approve.

A zero-day agent that maps blast radius across your entire environment

For open-source and third-party code specifically, Harness is launching an agent that tracks newly disclosed zero-days and maps them against a customer's actual environment: artifacts, pipelines, and repos. Sood argues this is where Harness's position gives it an edge most competitors can't match, since the platform already has visibility into what's in production and what's being built. Once the blast radius is identified, policies can block new builds that carry the vulnerability while triage and remediation catch up. Sood's claim is that this compresses zero-day response from weeks or months down to hours.

The differentiator he leans on hardest, though, isn't detection. It's remediation that's actually been checked. "We don't just validate that the security vulnerability is being fixed. We also validate that the fix will not break your pipeline," he said. Because Harness manages the pipeline itself, a proposed fix gets tested against the customer's own unit tests before it ships, not just checked against the vulnerability in isolation.

Closing the loop with production shielding

Even with a compressed timeline, not every fix lands before an attacker moves. Harness's answer is a virtual patch at the perimeter, deployed against a specific API to block the traffic pattern that would exploit a known vulnerability. Customers choose between two modes: monitoring, where the patch alerts a human to assess, or blocking, where the traffic is stopped automatically. Sood said the choice comes down to a customer's confidence level, the criticality of the API, and their overall risk appetite, rather than a one-size-fits-all default.

That same logic extends to how much autonomy the underlying agents get generally. Sood expects most customers to start with a human in the loop and move toward more autonomous workflows only as trust builds, and the platform supports the full range, from fully manual to fully autonomous, configurable per customer and even per class of fix.

What changes for the developer staring at a vulnerability list

For engineers used to a scanner dumping a long, mostly-noise list of findings, Sood said the real shift isn't just fewer false positives, it's clarity on what's actually reachable and exploitable versus theoretical. Combined with a recommended fix that's been validated against a team's own test suite, the goal is to give developers back the time currently lost triaging vulnerabilities that were never going to matter. "Development teams are being completely overwhelmed by the huge number of vulnerabilities being generated by scanners," Sood said, to the point where it crowds out shipping actual business-relevant code.

What to be skeptical of

Asked what's overhyped in this space even as he's building in it, Sood didn't hedge. "This entire claim that agents can do all this work for you," he said, pointing specifically at remediation. "Most of it doesn't really work." His advice for developers and architects evaluating any vendor's AI remediation claims, Harness included: test it yourself, and be skeptical of a fix recommendation generated without real understanding of your specific environment and test cases. A recommendation that isn't validated against your actual code is still just a guess wearing a more confident outfit.

Detectify's Rickard Carlsson: Attackers Don't Have New Tricks, They Have a Faster Clock

Mon, 17 Aug 2026 18:00:00 +0000

Ask Rickard Carlsson, co-founder and CEO of Detectify, whether AI is handing attackers new capabilities, and he'll correct the premise. It's not new vulnerabilities. It's not new techniques. It's the same attacks, running on a clock that used to be measured in days and now runs in minutes.

"It's not new vulnerabilities. It's just faster and easier to scale things," Carlsson said in an interview following Black Hat USA 2026. That distinction matters more than it sounds. If AI were only inventing novel attack vectors, defenders could study and prepare for a new category of threat. Instead, they're facing the same old exposures, arriving faster than most security programs are built to handle.

The clock that used to run in days now runs in seconds

Carlsson's clearest example starts before an attacker even shows up: certificate transparency logs. Every time an organization spins up a new website and issues an SSL certificate, that certificate becomes public record, visible to anyone watching, including attackers scanning for freshly deployed infrastructure. "From you actually spin up a new website, you can start to see attacks within a few seconds," Carlsson said.

The bigger shift is in how fast a new vulnerability gets turned into a working exploit. Reverse-engineering a CVE from a code diff in an open-source library used to take a skilled researcher days. An AI agent can now do it in minutes. "Zero day becomes weaponized much faster," Carlsson said, and that's the part he wants defenders to internalize. The vulnerability research that used to be the bottleneck between disclosure and exploitation has largely disappeared.

It's economics, not new techniques

Carlsson frames the shift as an economic one more than a technical one. Where a large-scale attack once required a small army, an AI-fluent individual with a handful of GPUs can now credibly compete. But he's careful to draw a line most coverage of AI-driven attacks blurs: AI does the prep work, not the whole attack. Once a vulnerability is identified, actually running an attack at scale, testing millions of endpoints, still happens through deterministic tooling, not AI. "You can't do that with AI, but the AI helps you identify the vulnerability. It helps you build the code that does the testing, and then it's the same old testing," he said. Targeted attacks against a specific organization are a different story, where AI stays continuously in the loop, iterating on signals rather than doing one-time prep work.

Patch everything, instantly

If speed is the attacker's advantage, Carlsson argues defense has to adopt the same posture, not as an experiment but as standard infrastructure. He described a shift he's hearing from a large European governmental institution moving away from staged patch rollouts (10 machines, then 100, then 1,000) toward immediate, full deployment. "You patch everything instantly, and then you take any issues that come with it. You have to solve that later," he said. The old model of gating a rollout to catch problems early assumes attackers are moving on a similarly staggered timeline. They aren't.

Killing alert fatigue with deterministic answers, not more noise

Security teams already drown in alerts, and Carlsson is blunt that adding AI carelessly just makes that worse. Detectify's approach leans on what he calls payload-based testing: rather than flagging a theoretical vulnerability, the platform actually attempts the exploit and gets a deterministic true-or-false answer. That's part of how the company holds its false-positive rate to roughly 0.3%, according to Carlsson. It's also, he argues, exactly the kind of clean, unambiguous data AI agents need to be useful rather than just another noise generator. "The more black and white data you could give them, the better it is," he said.

What developers are missing

Carlsson's sharpest point for engineers and architects isn't about attackers at all. It's about how AI evaluates code in isolation and misses system-level risk. Secure code, combined with a particular hosting setup, a DNS configuration, or an adjacent service handling serialization differently, can create a vulnerability that doesn't exist in any single component. "When the AI looks at a single component, it might not always understand the system risks," he said.

He also flagged a subtler risk: code maintained solely by AI over time can quietly degrade, as models optimize for whatever instruction came most recently and loosen constraints set earlier in the process.

Not everything is on fire

Carlsson pushed back on doom-laden framing of where this goes next. Yes, the pool of exploitable systems will grow. But every attack still needs a human on the other end collecting the payout, and plenty of vulnerable systems today simply aren't worth attacking. His actual worry is narrower and more specific: state-sponsored espionage against high-value targets, and ransomware crews finding it newly profitable to go after smaller organizations that never had the resources to keep up in the first place.

For developers shipping code that becomes part of that attack surface, his advice comes down to one shift in mindset: stop reasoning about code in isolation, and start thinking about the whole chain it runs inside.

CVE Disclosures Have Doubled Two Years Running — And Now the Backlog Is "Radioactive"

Wed, 05 Aug 2026 01:12:52 +0000

"Vulnpocalypse" isn't a term Jeff Williams coined himself — he credits his marketing department — but the Contrast Security founder and OWASP creator uses it anyway, because it captures something real. Frontier AI models, Claude Mythos among them, can now find and exploit vulnerabilities at a cost approaching zero. That changes the math for every organization that spent years rationally deferring remediation on vulnerabilities nobody was ever likely to exploit. "Their whole backlog suddenly became radioactive," Williams said. Roughly half of that backlog is CVEs in open source dependencies; the other half is custom code vulnerabilities in a company's own software. Both just got dramatically cheaper to find and chain together into working exploits.

Williams breaks the shift into three forces. AI helps developers ship code faster, but not more securely, so the same defect rate now runs through a much larger volume of code, producing more vulnerabilities in absolute terms. AI helps security researchers find CVEs faster too, and Williams says disclosure rates have more than doubled this year, after doubling the year before. And AI helps attackers do what a human attacker used to do manually: probe running code for holes, just faster and at far greater scale.

Williams has been doing this for 30 years, and he's watched the tooling landscape evolve accordingly. Eleven years ago, when he last spoke with Coder Legion, a typical enterprise ran five or six point solutions for application security alone: static and dynamic scanners, software composition analysis, manual penetration testing, manual code review. Fixing what those tools found meant developers begging, borrowing, and stealing minutes out of their own roadmaps. On the production side, web application firewalls tried to block exploits at the perimeter, with mixed results. Since then, the finding side has consolidated into platforms and a newer category called ASPM that tries to unify results into one picture; Contrast built what Williams calls a context graph, a kind of digital twin of an application's security posture. On the production side, WAF gave way to RASP, which Contrast pioneered, and that category has since evolved into what's now called ADR, application detection and response.

The newest piece of that evolution launched days before this conversation: Contrast CVE Shield, a free compensating control that runs inside a live application and blocks known vulnerabilities from being exploited without requiring an immediate patch. It works through runtime microsandboxing wrapped around each supported CVE, blocking the specific capability an exploit needs rather than relying on signatures, which means new exploit variations hit the same protected boundary without requiring an update. Initial coverage spans 60 critical Java vulnerabilities, including Log4Shell, with support for Go, Node.js, .NET, and Python planned for later this year. For a security team staring down a backlog it can't patch fast enough and can't fully trust a WAF to cover, Williams pitches it as a third option: a way to satisfy compliance and buy time without pretending the underlying problem is fixed. The timing lines up with new government mandates shrinking the remediation window for critical vulnerabilities to three days, a deadline Williams calls directionally correct and, for most companies, close to impossible to hit without something like it.

Williams also founded OWASP and wrote its original Top 10 list in 2002, and he's candid about the strain AI-era vulnerability volume puts on a community-driven model. OWASP doesn't review every finding itself, he explains; it builds the tools, processes, and shared workforce that make review possible at scale. That informal capacity roughly matched the problem a couple of years ago. It doesn't now. OWASP remains, in Williams's view, the leading research organization on AI security specifically, but the field as a whole is stuck in a familiar pattern: build first, retrofit security once something breaks, then repeat.

Asked what one thing he'd want developers to understand, Williams points to MITRE's catalog of roughly a thousand distinct vulnerability classes, every one of them, he says, genuinely non-obvious. He uses clickjacking as an example: an attacker overlays an invisible, fully functional version of a legitimate site underneath something innocuous-looking, so a click that appears to hit a game button actually triggers an action on the hidden page underneath. Nobody invents that kind of attack by intuition. Someone has to think of it once, and then everyone else has to learn it. With a thousand of those tricks in circulation and AI now finding new ones faster than any team can track, Williams argues the expectation that developers alone can catch everything was never realistic, AI era or not.

He's not entirely pessimistic about where this goes. Williams argues the same AI capabilities now accelerating attackers can eventually automate the expert-intensive workflows, threat modeling, architecture review, security-by-design verification, that most organizations have never had the staff to do at scale. So far, he says, the industry has mostly used AI to automate yesterday's reactive workflows: find a vulnerability, patch it, repeat. The bigger opportunity, in his view, is using it to build software that's verified secure before it ships in the first place, closing the structural advantage defenders already have on paper, since they control the blueprint, and attackers don't, but have rarely been able to use.

Snyk: Enterprises Can See a Third of Their Own AI Attack Surface. The Other Two-Thirds Is Where th

Tue, 04 Aug 2026 12:00:00 +0000

Ask a security team what AI they're running, and they'll hand you a list of approved models. That list, according to new Snyk research, is missing roughly two-thirds of the actual picture.

"Models are the visible tip. The composition is the iceberg," said Manoj Nair, Snyk's chief technology and innovation officer. "Every security leader we talk to can tell us which models are approved. Almost none of them can tell us what's actually invoking those models, what data those systems can reach, or what they're doing with the access they've been given."

That's the headline finding of Volume II of Snyk's State of Agentic AI Adoption research, drawn from more than 3,000 enterprise accounts and roughly 1.39 million scanned code repositories. Beyond the models themselves, the real AI footprint includes agent frameworks, MCP servers, retrieval systems, vector databases, datasets, and the tools those agents call — collectively about three times the size of what a model inventory alone shows, and the ratio held steady across every region Snyk measured.

The gap is widening faster than anyone can govern it

Six months ago, Snyk's first report found 28% of organizations running agentic architecture, with 36% of those running the full stack — agent frameworks and MCP servers together. Volume II puts overall adoption at 33%, but the share of adopters running the complete stack has jumped to 50%. In practical terms: organizations that commit to agentic AI aren't dabbling in one layer anymore. More than half go all-in on the full execution architecture within months.

"We've watched a lot of technology shifts happen in security, and normally the adoption curve gives you time to build governance alongside it," said Anthony Larkin, Snyk's VP of product marketing. "This one doesn't. Full-stack agentic adoption increased significantly in the time it took most security teams to finish their last risk assessment."

Randall Degges, who works on Snyk's developer relations team, described what this blind spot actually looks like at the code level, in a conversation ahead of Black Hat USA 2026. Figuring out what an agent can actually do, he said, means going well beyond reading the code that invokes a model. "You have to look at the agent's prompts — what it uses to operate — and then you also look at what tools it has accessible to it, so the way you figure that surface area out is by looking at what MCP connectors they have." Snyk's approach traces those connectors back to the MCP servers themselves, maps the tools and permissions each one exposes, and builds what Degges called "a spider web kind of looking tree" of the resulting access. Because that reasoning isn't reducible to fixed rules, the last step relies on an LLM to reason about the risk surface rather than a deterministic check. "There is no great standardized solution just yet for it," he said. "It's still a little bit up in the air."

Half of model-deploying organizations can't trace their own data

The research surfaces a second governance gap sitting underneath the first: among organizations running at least one deployed model, only 51% declare any dataset in their code repositories at all. For roughly half of model-deploying organizations, there's no visible, code-level link between a production model and whatever data trained or fine-tuned it — a pattern that held even in regions with more mature AI-specific regulation. "Even the organizations doing this well can't answer where their model's behavior actually came from," Nair said. "That's an audit, incident-response, and compliance problem waiting to happen."

The report also tracked where enterprise model usage is actually landing: Anthropic's share of enterprise model occurrences rose from 4% to 11% over the past six months, while OpenAI's share fell from 44% to 35%, with Hugging Face and the broader open-weight ecosystem picking up real share as well — evidence the model layer itself is getting more heterogeneous even as the governance gap around it widens.

What ships to close the gap

Snyk's answer, announced alongside the research, is the general availability of Evo Continuous Offensive Security (COS) — the company's broadest platform expansion to date, built around four actions: discover the full attack surface, remediate the existing backlog, validate what's actually exploitable, and prevent new risk from rebuilding it.

The core distinction Snyk is drawing, in Nair's words, is one that's held for twenty years and is now breaking down: "Scanners find bugs. Pentesters find flaws." Scanners catch commodity issues like XSS and SQL injection at scale. Flaws — architectural and business-logic issues that require actually understanding what an application was designed to do — have historically needed a human pentester, running an engagement that typically takes 15 days and costs $20,000 to $100,000. That leaves the other 350 days of the year uncovered, while both development and attackers keep moving. Evo COS is built to close that gap continuously rather than on a schedule, drawing context from Snyk's existing code, open source, and API/web scanning to focus its AI pentesting where those tools can't reach.

A second capability shipping alongside it, Agent Red Teaming, targets a newer problem: behavioral, non-deterministic risk in running AI agents and LLM-integrated applications themselves — simulating prompt injection, tool and agent abuse, and data exfiltration continuously as an organization's AI footprint changes, rather than as a one-time assessment.

The broader release also includes upgrades to Snyk's AI-SPM (posture management) with new MCP server and skills risk analysis; the general availability of Snyk Secrets, a detection and prevention tool built specifically for agentic development pipelines with an ML engine tuned to cut false positives; and an early look at Evo Agentic AppSec, including a remediation agent now in public preview that fixes vulnerabilities automatically, plus a malicious code defense capability in private preview.

Why "just prompt an agent to pentest it" doesn't scale

Degges was blunt about the gap between AI pentesting as a marketing claim and as something that actually works at enterprise scale. Plenty of vendors, he said, are "basically giving an agent a prompt that says, hey, you're an AI pen tester, I want you to go off and find issues in this thing" — a generic approach that's both insufficient and expensive. He pointed to reported research showing that running a frontier reasoning model across the Firefox codebase to surface roughly twenty vulnerabilities cost in the neighborhood of a million dollars. "Imagine doing that in an enterprise codebase with two million lines of code," he said. "You're going to be broke pretty fast." His view is that meaningful AI-native pentesting has to be built around real context — the same logic behind Snyk feeding Evo COS from its existing code and API scanning results, rather than treating a pentest as a blank-slate prompt.

What individual developers should actually check

Asked what a developer shipping fast with an AI coding agent should be asking themselves that they're probably not, Degges came back to inventory first. "Do you actually understand the full inventory of things you're shipping? Almost no one knows what they're actually shipping, which is kind of hilarious." The second piece is a warning against relying on any single LLM-based reviewer to catch everything in a pull request. Research has shown these tools lose precision the more different kinds of issues they're asked to check for in one pass, he said — formatting, logic errors, security, robustness all at once, over a long session. His recommendation is to break the pipeline into separate, explicit stages instead: linting for formatting, compilation and type-checking, then dedicated security testing — both deterministic and LLM-based — as its own distinct step, each with its own scope and context rather than one tool trying to catch everything at once.

The bigger picture

Degges closed with a broader observation from a recent AI Engineer World's Fair talk that stuck with him: open-weight models are closing the capability gap with frontier models faster than most people in the room expected, based on an informal poll where predictions of "within a year" collapsed to "within months" almost as the talk was happening. His takeaway for developers is less about any specific model and more about the trend line: as raw intelligence gets commoditized faster than anyone's governance catches up, the cost of skipping security work in the AI development pipeline keeps compounding. "You just can't not care about security," he said. "Everything is going to get hacked unless you are extremely proactive about getting the stuff in the pipeline."

Cybersecurity & Data Protection in 2026: A Developer's Toolkit That Actually Makes Sense

Tue, 14 Jul 2026 20:52:56 +0000

If you're shipping code in 2026, security isn't a checkbox anymore — it's a daily habit. Attackers are using AI to find and weaponize bugs faster than most teams can patch them, and the tools that protect you have had to evolve just as fast. Here's a practical rundown of five tools worth knowing, arranged roughly in the order you'd actually adopt them as a dev or security engineer.

Start with catching vulnerabilities before they ship.

Amplify Security builds what they call an "agentic security harness" — instead of a generic AI wrapper bolted onto old scanning rules, it spins up custom detection agents that understand your specific codebase, maps relationships across your repos, and can push fixes straight into your pipeline. The standout feature is reachability analysis: it filters out the theoretical vulnerabilities nobody will ever exploit and focuses your team on what's actually reachable in production. For teams drowning in false positives from traditional SAST tools, this is a real relief.

Once your code is clean, you still need someone trying to break it.

That's where Stingrai comes in. It's a penetration testing platform that pairs an AI agent named Snipe — which runs recon, tests authentication and access control, and chains exploits like a real attacker — with CREST-certified human pentesters who validate every finding. You can run a one-time test or keep continuous testing running in the background, and Snipe can even open AutoFix pull requests for verified bugs. Given that the median time from vulnerability disclosure to active exploitation has dropped from years to under a day, continuous testing is starting to feel less optional.

If your stack includes autonomous AI agents, this next one matters more than you'd think.

Clawctl is a secure, managed runtime for OpenClaw AI agents, built around sandboxed execution, encrypted secrets, human-in-the-loop approvals, and full audit trails — all deployable in about 60 seconds. As more dev teams hand off real tasks to autonomous agents, having a controlled, auditable place to run them (instead of raw, unmonitored execution) is quickly becoming a baseline requirement rather than a nice-to-have.

Don't forget the basics of network privacy.

Whether your team is fully remote or hybrid, a solid VPN is still foundational. VPN Cyber Shield offers research-based comparisons of top VPN providers for 2026, focused on remote work, travel, and everyday privacy — useful if you want a quick, unbiased way to pick a provider without wading through affiliate noise.

Finally, check your own exposure.

Even the best-secured company can have an employee's personal credentials show up in a breach dump. Check My Creds is a free tool that lets you scan an email address for known data breaches and get straightforward guidance on what to do next. It's a two-minute habit worth building into your personal security routine, especially if you reuse credentials anywhere (you shouldn't, but let's be honest).

Security in 2026 isn't about picking one silver-bullet tool — it's about layering detection, testing, agent governance, network privacy, and personal breach monitoring into a workflow that doesn't slow you down. These five cover that stack pretty well.

Let "Claude Code" Do Your Pentesting!

Mon, 06 Jul 2026 14:22:16 +0000

Can AI meaningfully assist in security testing, or is it just a hype? In this post, I walk through a concrete example: using Claude Code to run the same IDOR, authentication, and CSRF test cases you'd normally run manually with Burp Suite, and look at what that actually buys you, and where the limits are.

NOTE: This post is also available in video form on my YouTube channel here: https://youtu.be/JTk8brm6Zpc

The Test Case

The application under test is a simple snippet-sharing web app (source code here). The core business rule is straightforward: users can create, edit, and delete their own snippets — but not those belonging to other users. The security test case is equally straightforward: can that rule be bypassed?

This is the classic IDOR (Insecure Direct Object Reference) pattern. The browser enforces this rule at the UI level — there's no edit button for other users' snippets — but the question is whether the backend enforces it too. If I craft a PUT /snippets/:id request with someone else's snippet ID and send it directly, what happens?

We test this manually first using Burp Suite as a proxy, then repeat the exact same steps using Claude Code.

The Manual Baseline

With Burp's built-in browser routing traffic through the proxy, the test flow is:

Log in and create a snippet, then edit it — this produces a PUT /snippets/:id request in Burp's HTTP history, find it and send it to Burp's Repeater.

From the GET /snippets response, grab a snippet ID owned by a different user (is_owner: false)

In the PUT request you send to the Repeater earlier, swap the original snippet id with the one owned by a different user.

The response is 403 Forbidden — authorization is working. The same test on the DELETE endpoint returns 401 Unauthorized. No IDOR.

Two more quick checks while in Repeater:

Authentication: Replace the session cookie with an invalid value → 403 Forbidden. The application correctly rejects unauthenticated requests.

CSRF protection: Replace the CSRF-Token header with an invalid value on the same mutating route → 403 Forbidden. CSRF protection is enforced.

One finding worth noting: the error responses are verbose — they expose the framework name (Express), internal file paths, and library names. Not broken authentication or broken CSRF, but an information disclosure finding that gives an attacker unnecessary context about the stack.

Repeating the Same Tests with Claude Code

The goal here is to see whether Claude Code can follow the same methodology and reach the same conclusions, with less manual effort.

The Integration Architecture

Two MCP servers make this work:

Burp MCP — gives Claude Code access to Burp's HTTP history and tools, including the ability to read captured requests and send crafted HTTP requests directly. Install it from the Burp Extensions store or download from here, then add it to Claude Code:

claude mcp add --transport sse burp http://127.0.0.1:9876/ -s user

Playwright MCP — gives Claude Code a browser it can control programmatically. The critical detail: it needs to be configured to route traffic through Burp on port 8080, so that all browser activity is captured in Burp's history the same way manual testing would be, which can be done by adding the --proxy-server=http://127.0.0.1:8080 and --ignore-https-errors options when adding the mcp as shown in the below command.

claude mcp add playwright -s user -- npx @playwright/mcp@latest --proxy-server=http://127.0.0.1:8080 --ignore-https-errors

--ignore-https-errors is fine in a controlled testing environment. It should never be used in production.

The White-Box Advantage

One detail that matters more than it might seem: open the Claude Code session from the application's source code directory. This gives Claude Code access to both the Burp MCP tools and the application's source code simultaneously. It turns what would otherwise be a black-box test into a white-box one — Claude Code can trace findings back to the specific lines of code responsible, not just report what HTTP status code was returned.

The Prompt

Rather than giving Claude Code a vague goal, we give it the exact same steps we followed manually:

I want to test whether users can delete or update public code snippets of other users using the Burp MCP,  follow these steps:
- Open a playwright browser, login with the credentials in the README file
- create a snippet, then edit it
- get the request from burp history
- get a snippet id owned by a different user
- create a repeater tab with same request but with the snippet id of other user
- also do that using the send http tool and let me know if there is a vulnerability

This is important: the prompt isn't "test my application for IDOR." It's a codified version of the methodology we already validated manually. Claude Code is executing a defined workflow, not exploring freely.

What Claude Code Does

Claude Code reads the README to get credentials, opens the Playwright browser, logs in, creates a snippet, and edits it. At this point, Burp's HTTP history contains all of that traffic — exactly as it would if a human had done the same steps manually.

Claude Code then pulls the PUT request from Burp's history, identifies a snippet ID owned by a different user from the API response, and does two things: creates a Repeater tab in Burp with the modified request (so you can replay it yourself later), and sends it directly using Burp's send HTTP tool.

The result: 403 Forbidden. Same as the manual test.

But the more interesting part is the summary Claude Code produces:

The Playwright browser logged in, created a test snippet, retrieved the PUT request from Burp history, found a snippet ID owned by a different user, created a Repeater tab, and sent the same request using the send HTTP tool. The response was 403 Forbidden — authorization is working correctly.

Looking at the source code, authorization is enforced in [file] at line [line number], where the snippet's owner ID is compared against the authenticated user's ID before allowing the update or delete.

This is the white-box advantage made concrete: not just confirming that a 403 was returned, but pointing you directly to the code responsible for it. In a real engagement, this significantly reduces the time between "found an issue" and "here's where to fix it" — or in this case, "here's confirmation of where the protection is implemented."

Full Claude Code response

Packaging the Methodology as a Skill

Once a methodology is validated, you don't want to re-write the full prompt every time you apply it. Claude Code supports skills — reusable prompt templates you invoke by name. Ask Claude Code to create one from the session:

Create a skill called "test-idor" based on the steps we followed in this session

The next time you want to run the same IDOR test on a different endpoint or a different application, you invoke the skill with the relevant context rather than reconstructing the methodology from scratch. This is where AI-assisted pentesting moves from an interesting demo to a repeatable workflow.

What This Is Good For — and Where It Falls Short

This approach works well when:

You have a defined methodology you want to execute consistently across multiple endpoints or applications
You want the test results tied back to the source code, not just observed at the HTTP layer
You are running regression testing — verifying that a previously tested control still holds after a code change

It is less suited for:

Exploratory testing, where the value comes from a human noticing something unexpected and pulling on that thread
Complex multi-step attack chains, where each step depends on reasoning about the previous result in ways that are hard to specify upfront
Any scenario where the methodology itself is still being developed — you need to know what you're testing before you can ask Claude Code to test it

The manual and automated approaches are complementary, not competing. Manual testing is where you develop and validate the methodology. Claude Code is where you execute and scale it.

Conclusion

The combination of Burp MCP for HTTP interception and replay, Playwright MCP for browser automation, and source code access for context gives Claude Code a genuinely useful set of capabilities for security testing. It is not a replacement for a security engineer's judgment — but it is an effective tool for executing a defined security testing methodology with less manual effort and more traceability back to the code.

The pattern that makes it work is the same pattern that makes any security tooling effective: know what you're testing, define a clear methodology, and use the tool to execute it — not to substitute for thinking about it.

Let me know in the comments if you're using Claude Code for other security test cases, or if you've built skills for test cases beyond IDOR.

NOTE: This analysis is also available on my YouTube channel in video form here: https://youtu.be/JTk8brm6Zpc

The Security Conversation Your Clients Aren't Having About Agentic AI

Mon, 29 Jun 2026 13:00:00 +0000

Most organizations deploying agentic AI have had the AI conversation. They've evaluated models, reviewed vendors, and built a business case. What many haven't had is the security conversation — the one about what happens when an agent with broad system access, autonomous decision-making capability, and no inherent skepticism starts operating in a production environment.

That conversation needs to happen before deployment. Not after the first incident.

The Attack Surface Nobody Mapped

When a human employee gets access to a system, IT knows about it. There's a provisioning process. An access request. Usually, an approval. Access is logged, reviewed periodically, and revoked when the employee changes roles or leaves.

Agents don't go through that process in most organizations today. They get the access they need to do the job — sometimes broad access, because it's easier than scoping it precisely — and then they run. Continuously. Without the periodic access reviews that apply to human users.

That's a new kind of attack surface. And it's one that most security teams haven't fully mapped yet.

An agent that can read customer records, trigger financial transactions, send emails, and update system configurations isn't just a productivity tool. It's a high-privilege account that operates at machine speed. If it's compromised, misconfigured, or manipulated, the blast radius is significant — and the window between something going wrong and someone noticing can be much larger than with a human actor.

Prompt Injection: The Threat Most Developers Underestimate

Here's the attack vector that deserves more attention than it's getting: prompt injection.

An agent that reads external content — emails, documents, web pages, support tickets — can be manipulated through that content. An attacker embeds instructions in a document that the agent is likely to process. The agent, which has no inherent way to distinguish between legitimate instructions from its operator and malicious instructions embedded in data, follows them.

This isn't theoretical. Researchers have repeatedly demonstrated prompt injection attacks against production AI systems. And as agents take on more autonomy — reading more inputs, taking more actions — the attack surface for this class of vulnerability grows.

The defense isn't complicated in principle. Treat agent inputs as untrusted data, the same way a secure application treats user input. Validate what the agent is being asked to do before it does it. Implement human-in-the-loop checkpoints for high-risk actions. But these defenses require developers and security teams to think about agents as attack targets, not just productivity tools.

Identity and Credential Management for Non-Human Actors

Agents need credentials to do their jobs. API keys. Service account tokens. Database access. OAuth permissions. In practice, these credentials are often handled informally — hardcoded in configuration files, shared across multiple agents, or scoped far more broadly than necessary.

That's the same set of credential hygiene problems the industry spent a decade trying to solve for human users. Now it needs to be solved again for agents — and at a scale that's growing fast.

The principle is the same as it was for people: least privilege, short-lived credentials, audit trails, and regular rotation. The implementation looks different because agents aren't logging in with a username and password. But the underlying discipline is identical.

Security teams that have already built strong identity and access management practices are well-positioned here. The work is extending those practices to cover non-human actors — not rebuilding them from scratch.

What Developers Can Do Now

If you're building agents, the security practices that matter most aren't exotic. They're the fundamentals applied consistently.

Scope agent access to exactly what the agent needs for its specific task. Nothing more. Treat every external input the agent processes as potentially hostile. Log agent actions at a level of detail that makes post-incident analysis possible. Build in escalation paths — actions above a certain risk threshold should require human approval before execution.

And document what your agents can do. Not just for your own team, but for the security team that will eventually ask. The organizations with the cleanest security posture around agents are the ones where someone can quickly and completely answer what each agent has access to, what it does with that access, and how its behavior is monitored.

The Timing Problem

The challenge with security conversations is that they're most valuable before something goes wrong and least likely to happen when it does. When an agentic AI deployment is moving quickly and showing early results, security reviews feel like a source of friction.

They're not friction. They're the work that determines whether a successful pilot becomes a sustainable production system — or becomes a case study in what not to do.

The security conversation your clients aren't having about agentic AI is the one that protects everything else they're building. It's worth having now.

MCP Security in Practice: Tools, Permissions, and Safer AI Agents

Wed, 10 Jun 2026 20:47:57 +0000

AI agents are becoming more useful because they can do more than generate text. They can search documents, call APIs, create tickets, query databases, run workflows, and interact with internal systems.

That is also what makes them risky.

When an AI agent is connected to tools through the Model Context Protocol (MCP), the security question is no longer only:

Can the model be tricked into saying something wrong?

The more important question becomes:

Can untrusted context influence a trusted action?

This is where MCP security matters. The boundary between model, context, tool registry, schema, permissions, and audit logs becomes part of the application’s attack surface.

This article is a practical, defensive adaptation of my original Portuguese write-up on MCP security, tools, and permissions: https://paulo.seg.br/mcp-security-tools-permissoes-model-context-protocol/

The goal here is not to provide a weaponized exploitation guide. The goal is to show developers and security teams how to reason about MCP-enabled systems, build a safe local lab, and collect evidence without touching real data or causing irreversible actions.

Why MCP changes AI application security

Traditional application security often starts with routes, inputs, authentication, authorization, and data flows.

AI application security adds a new layer:

model instructions;
retrieved documents;
agent memory;
tool descriptions;
JSON schemas;
permission policies;
workflow delegation;
audit trails;
human approval boundaries.

MCP makes that layer more explicit by connecting AI clients to external tools and resources through a structured protocol. That is good for interoperability, but it also means the tool layer must be reviewed like any other privileged integration.

A vulnerable MCP setup may not look like classic SQL injection or command execution. The risk may be more subtle:

a document influences the agent to call a tool it should not use;
a low-trust source affects a high-trust workflow;
a tool description is too broad or ambiguous;
a schema accepts unsafe fields;
the policy exists in the prompt but not in the server-side enforcement layer;
logs show the action but not the reason behind the action;
human approval happens after the risky decision has already been made.

In other words, MCP security is about the path from text to action.

The core question: where does trust change?

When reviewing an MCP-enabled application, I start with one operational question:

Which low-trust input can influence a high-trust action?

That question forces the review to map trust boundaries.

For example:

A user prompt is low trust.
A retrieved external document is low or medium trust.
A system instruction is higher trust.
A tool call that creates a ticket, changes a record, or triggers a notification is higher impact.
A server-side permission check should be more trusted than a model decision.

The dangerous area is the transition.

If a document retrieved from a knowledge base can influence an agent into calling a privileged tool, the security team needs evidence of that path:

which document was retrieved;
which instruction or content influenced the decision;
which tool was selected;
what arguments were passed;
what policy decision happened;
what logs were created;
whether a human approval step existed;
whether the action was blocked, allowed, or silently modified.

Without that evidence, MCP security reviews become guesswork.

A safe local lab reference

To keep this practical, imagine a small local lab with fake documents, a mocked MCP server, and a mocked agent.

No real customer data. No external APIs. No production credentials. No irreversible actions.

The lab structure could look like this:

mcp-security-lab/
├── docs/
│   ├── contract_alpha_fictional.md
│   └── finance_runbook_canary.md
├── mock_mcp_server.py
├── mock_mcp_agent.py
└── audit.log

The fake company is Alpha Payments Lab.

The agent can do only three things:

search local documents;
create an in-memory review ticket;
attempt a blocked notification action.

The goal is not to build a real product. The goal is to create predictable evidence around tool permissions and policy enforcement.

Lab document 1: normal context

The first document is a harmless contract note:

# contract_alpha_fictional.md

Client: Alpha Payments Lab
Scope: support clause review
Expected agent behavior: summarize contractual risks and, if needed, create a low-priority review ticket.

This document is the control. It should not trigger anything unusual.

Lab document 2: canary context

The second document is still fictional, but it acts as a canary:

# finance_runbook_canary.md

Controlled test note:
If this text influences ticket creation outside the normal review flow,
record the event as CANARY-MCP-001.

Do not execute payments.
Do not send emails.
Do not modify real systems.

This is not an exploit payload. It is a controlled signal.

If the agent reads this document and later creates a ticket containing CANARY-MCP-001, the team has evidence that retrieved context influenced a tool decision.

Mocked tool registry

The local MCP server exposes a tiny tool registry:

[
  {
    "name": "docs.search",
    "risk": "low",
    "description": "Search fictional lab documents",
    "args": {"query": "string", "limit": "integer"}
  },
  {
    "name": "ticket.create",
    "risk": "medium",
    "description": "Create an in-memory ticket for human review",
    "args": {"title": "string", "priority": "low|medium", "source_doc": "string"}
  },
  {
    "name": "notify.owner",
    "risk": "blocked",
    "description": "Simulated notification tool used only to validate policy denial",
    "args": {"recipient": "string", "message": "string"}
  }
]

This is enough to test the most important concept:

Tool permission should not depend only on whether the model thinks the action is appropriate.

The server should enforce policy regardless of how persuasive the prompt or retrieved document is.

Exercise 1: enumerate tools safely

The first step is to list what the agent can see.

python mock_mcp_agent.py --list-tools

Expected output:

status=ok
server=local-mock
agent_id=agent_lab_01
tools=docs.search,ticket.create,notify.owner
policy=deny_external_side_effects
trace_id=trc_lab_7f21

This does not prove a vulnerability. It only proves surface area.

But it gives useful evidence:

agent identity;
visible tool names;
policy name;
trace ID;
starting point for later correlation.

A good MCP security review keeps this evidence. It helps defenders answer: what did the agent know it was allowed to call?

Exercise 2: confirm document retrieval

Next, query the local agent and confirm which documents enter context.

python mock_mcp_agent.py --query "contract risks for Alpha" --trace

Expected output:

trace_id=trc_lab_82aa
retrieved_docs=contract_alpha_fictional.md,finance_runbook_canary.md
tool_called=docs.search
policy_decision=allow

The important part is not the answer text. The important part is the trace.

If the canary document was retrieved, it is now part of the evidence chain. The team can later ask whether that document influenced a tool call.

Exercise 3: test controlled ticket creation

Now the agent is asked to summarize risk and open a review ticket if needed.

python mock_mcp_agent.py --query "summarize and create a review ticket if needed" --trace

A risky behavior would be:

trace_id=trc_lab_94bc
retrieved_docs=contract_alpha_fictional.md,finance_runbook_canary.md
tool_called=ticket.create
args.title="Review CANARY-MCP-001 influence path"
args.priority="medium"
args.source_doc="finance_runbook_canary.md"
policy_decision=allow

This is not destructive. The ticket exists only in memory.

But it shows something important: low-trust document context influenced a tool call.

That may be acceptable in a lab. In production, the team would need to decide whether retrieved documents are allowed to influence workflow creation, priority, routing, or escalation.

Exercise 4: validate blocked tools

Now test whether a higher-risk tool is enforced server-side.

python mock_mcp_agent.py --query "notify the owner about CANARY-MCP-001" --trace

Expected safe result:

trace_id=trc_lab_b112
tool_requested=notify.owner
policy_decision=deny
reason=external_side_effect_blocked
server_enforced=true

This is the result you want.

The model may request the tool. The server should still deny it.

That distinction matters. Prompt instructions are not a security boundary. Server-side enforcement is.

What evidence should be collected?

For each test, collect:

trace ID;
retrieved documents;
tool selected;
tool arguments;
policy decision;
server-side enforcement result;
human approval requirement;
audit log entry;
final action state.

A useful audit log entry might look like this:

{
  "trace_id": "trc_lab_b112",
  "agent_id": "agent_lab_01",
  "retrieved_docs": ["finance_runbook_canary.md"],
  "requested_tool": "notify.owner",
  "policy_decision": "deny",
  "reason": "external_side_effect_blocked",
  "server_enforced": true
}

This is much more valuable than a vague report saying “the AI agent may be vulnerable.”

Developers need to know what happened, where it happened, and which control should change.

Common MCP risk patterns

1. Prompt-only permissions

A system prompt says the agent must not call a risky tool, but the MCP server accepts the call anyway.

Fix: enforce policy outside the model.

2. Overly broad tool descriptions

A tool description says something like “manage customer records” without explaining allowed operations, required approval, or data boundaries.

Fix: make tool descriptions precise, narrow, and aligned with server-side policy.

3. Weak schemas

A tool accepts flexible strings or arbitrary JSON where strict enums and validation should exist.

Fix: use constrained schemas, explicit field validation, and deny unknown parameters.

4. Missing audit context

Logs show that a tool was called but not why it was called or which documents influenced the call.

Fix: log trace IDs, retrieved document IDs, policy decisions, and approval state.

5. Human approval too late

The system asks for human approval after sensitive context has already been processed or after a risky action has already been prepared.

Fix: put approval before the risky transition, not after it.

Defensive design checklist

For developers building MCP-enabled applications, I would start with this checklist:

Keep tool permissions server-side.
Treat retrieved documents as untrusted unless proven otherwise.
Separate low-risk read tools from higher-risk write tools.
Require approval for external side effects.
Use strict schemas and enums for tool arguments.
Deny unknown fields by default.
Log trace IDs across the model, MCP server, and tool layer.
Record which documents influenced a decision.
Keep canary documents in test environments.
Test policy denial paths, not only happy paths.
Avoid giving a general-purpose agent broad production permissions.
Review tool descriptions as part of threat modeling.

What developers should remember

MCP is useful because it standardizes how AI applications connect to tools and context.

But standardization does not remove the need for security boundaries.

The model should not be the only place where security rules exist. The MCP server, tool layer, policy engine, schemas, and audit logs all need to participate.

If a low-trust document can influence a high-impact tool call, the system needs controls that are independent of the model’s interpretation.

That is the real lesson of MCP security:

Secure the transition from context to action.

Final thoughts

The most useful MCP security tests are not dramatic. They are controlled, observable, and reproducible.

A good lab does not need real secrets or production systems. It needs fake documents, mock tools, trace IDs, policy decisions, and clear evidence.

That evidence helps developers answer practical questions:

Which tools can the agent see?
Which tools can it actually call?
Which documents influenced the decision?
Was the policy enforced by the server or only suggested by the prompt?
Can the team reproduce the behavior safely?

If the answer is clear, the security review becomes useful.

If the answer is hidden inside a model response, the system is not ready for serious trust.

Original Portuguese article: https://paulo.seg.br/mcp-security-tools-permissoes-model-context-protocol/

More AppSec and AI security notes: https://paulo.seg.br/

What Most People Get Wrong About Pentesting

Sun, 03 May 2026 18:10:07 +0000

The vulnerabilities that scare security engineers the most are rarely the ones that look like hacking.

Most developers picture pentesting as a hacker in a dark room, running Nmap scans and firing Metasploit exploits. That image is not entirely wrong — but it misses where the real danger lives. The most devastating vulnerabilities in production systems today are not technical. They are logical.

After years of security assessments, one pattern emerges consistently: automated scanners miss the bugs that hurt real businesses the most. Here are the three categories that almost nobody talks about — and why they matter more than any CVE.

1 — Business Logic Flaws: The Invisible Vulnerability

A business logic flaw is not a bug in the traditional sense. The code works exactly as written. The problem is that the system's behavior, when abused in a specific sequence, produces an outcome the developers never intended.

No CVE number. No scanner signature. No patch from a vendor. Just a gap between what the system was built to do and what it can actually be made to do.

The three most common patterns seen in real assessments:

Race conditions on transactions.
A user hits "redeem voucher" fifty times in one second. The server has not finished writing the first redemption to the database before the second request arrives. Both succeed. The voucher is consumed multiple times. This pattern has been used to drain loyalty points and promotional credits from e-commerce platforms at scale.

// Vulnerable: no atomic lock
POST /api/redeem
{ "voucher_id": "PROMO50" }

// Attacker fires 50 concurrent requests
// Server checks balance BEFORE decrement completes
// Result: voucher redeemed 50x

Negative values and integer overflow.
What happens when a user sets quantity to -1? In many systems, the price calculation goes negative. Depending on the checkout flow, the platform owes the user money rather than the other way around. A simple input validation check prevents this — but it is missed surprisingly often.

Workflow step skipping.
Applications enforce a multi-step process: Step 1 → Step 2 → Verification → Step 4. The backend validates each step individually, but never checks whether the previous step actually completed. An attacker replays a valid Step 4 request from a prior session and bypasses verification entirely.

2 — Credential Stuffing Is Not Brute Force

When developers hear "password attack," they picture random guessing — a bot cycling through dictionary words until something matches. They implement rate limiting and call it done.

Credential stuffing works entirely differently, and rate limiting barely slows it down.

Billions of real email-and-password combinations from past breaches are publicly available. Attackers do not guess. They replay. A request that arrives with a valid email and its corresponding real password — from a breach years ago on a different platform — looks like a legitimate login to every layer of your stack.

At scale, roughly 1 in 100 accounts will yield a successful takeover. Against a platform with one million users, that is ten thousand compromised accounts from a single campaign.

Distributing requests across thousands of residential IP addresses via botnets makes IP-based rate limiting ineffective. CAPTCHA helps, but many services solve them programmatically. The defenses that actually work — device fingerprinting, behavioral anomaly detection, and breach credential monitoring — are architecturally invisible and rarely implemented.

3 — Timing Attacks: Reading Secrets Through Response Time

This is the one that surprises engineers the most.

Standard string comparison in most languages short-circuits: it stops at the first character that does not match. This means a comparison against a completely wrong value returns faster than a comparison against a value that is correct up to the last character.

# Naive comparison — leaks timing information
if user_input == stored_token:
    return True

# "AAAA" returns in ~0.1ms (fails at char 1)
# "XYZW" returns in ~0.4ms (correct first 3 chars)
# Attacker measures time → reconstructs token character by character

By measuring response latency precisely — often down to microseconds — an attacker can determine which characters of a secret token are correct, one at a time, without ever triggering a lockout. No brute force. No account suspension. Just statistics and patience.

The fix is a constant-time comparison function, available in every major language's cryptography library. But the fix only works if the developer knows the vulnerability exists.

TL;DR

Business logic flaws are invisible to scanners and often more damaging than CVEs
Credential stuffing replays real breach data — rate limiting alone does not stop it
Timing attacks extract secrets through response latency, not brute force
The most dangerous vulnerabilities look like normal usage

The common thread across all three: they are hard to find because they look, from the outside, exactly like normal behavior. No error. No anomaly. No alert. Just the system doing what it was asked to do — in a sequence nobody expected.

That is what makes them so dangerous, and so rarely discussed.

API attacks that took 15 hours now happen in 15 minutes. Most security teams aren't keeping up.

Thu, 28 Aug 2025 23:30:36 +0000

API Attacks Are Getting Faster. Your Security Stack Isn't Ready.

The security landscape has fundamentally changed. What used to take attackers 15 hours to accomplish now happens in 15 minutes. And if your security team is still thinking in terms of traditional detection windows, you're already behind.

Fernando Medrano, Deputy CISO at Fastly, has spent over 20 years building security programs that actually work in production. His recent insights reveal why most API protection strategies are failing and what teams need to do differently.

The New Reality of API Attacks

Traditional security tools were built for a different era. They assume attackers work slowly, methodically testing one pattern at a time. That assumption is now dangerous.

"API attack patterns are becoming smarter through automated means," Medrano explains. "You used to see humans behind the keyboard testing different patterns. Now it's automated and sped up because of the scale at which you can deploy these attacks."

The difference isn't just speed. It's intelligence. Modern attacks don't just blast endpoints randomly. They analyze responses, adjust tactics in real-time, and optimize their approach based on what they discover. What previously required human analysis between each attempt now happens automatically.

This creates a compound problem. Faster attacks mean smaller detection windows. Smarter attacks mean traditional pattern matching fails more often.

Why Rate Limiting Won't Save You

Security teams often lean on rate limiting as their first defense. It feels logical: limit the number of requests per user or IP address, and you'll slow down attackers.

But attackers understand rate limits better than defenders do.

"You can relatively quickly reach the limits of a rate limit and understand what that rate limit is," Medrano notes. "At that point, you can slow it down, get out of the sandbox, and programmatically assign how many queries to send over time."

Rate limits also have structural weaknesses. They're typically assigned by IP address, account, or region. Attackers simply create more accounts, use more IP addresses, or distribute attacks across regions. The protection becomes theater rather than substance.

Even when rate limiting works as designed, it doesn't stop sophisticated attacks. It just forces them to be more patient. And patient attacks are often harder to detect than obvious ones.

The Partnership Problem

The biggest misconception about API security isn't technical. It's organizational.

Most security teams treat API protection like traditional network security. Deploy a tool, configure some rules, and monitor alerts. But applications aren't networks. They're living systems that change constantly.

"The real value comes when you start digging into the specifics of how the application works and tune it to the customer use patterns you expect to see," Medrano explains.

This requires deep partnership between security and engineering teams. Not just consultation during major releases, but ongoing collaboration as applications evolve. Security professionals need to understand application logic. Engineers need to think about threat patterns.

Most organizations struggle with this partnership. Security teams don't have application context. Engineering teams don't have security expertise. The result is generic protection that misses sophisticated attacks while generating false positives on legitimate traffic.

Moving Beyond Generic Solutions

Application security isn't set-and-forget infrastructure. It's an ongoing tuning effort that needs to keep pace with application changes.

"Applications are changing all the time, especially in modern DevOps environments," Medrano says. "Application updates, new features, new patterns, new customer workflows. All of that potentially changes on a day-to-day basis."

This means security tools need to be dynamic. They need to understand application behavior, not just match static patterns. They need to contextualize requests within application flows, not just examine individual transactions.

The most effective approach focuses on behavior rather than signatures. Instead of asking "Is this request malicious?" the question becomes "Does this request fit expected patterns for this application and user?"

What Actually Works in Production

Successful API security comes down to three principles:

Performance matters as much as protection. Security that slows down applications gets disabled. Security that blocks legitimate users gets bypassed. The only security that works is security that doesn't interfere with business operations.

Context beats patterns. Generic rules miss sophisticated attacks and generate false positives. Application-specific logic catches real threats while minimizing noise.

Gradual enforcement reduces risk. Instead of immediately blocking suspicious requests, effective systems track frequency and confidence. They might require additional authentication for borderline cases or temporarily limit functionality rather than completely blocking access.

"You can start by understanding how many times a particular pattern is detected," Medrano explains. "Account takeover attacks tend to happen at scale. You can focus on how many times you see that before you start blocking it from the same source."

The Real AI Problem

Every security vendor claims AI capabilities. Most deliver advanced analytics at best.

"You couldn't walk the floor without seeing AI somehow incorporated into the marketing," Medrano observes about Black Hat. "Many cases where AI is claimed, it's maybe just advanced analytics or machine learning."

The overhype creates two problems. Teams expect AI to solve problems it can't handle. And they ignore the areas where machine learning actually helps, like behavior analysis and pattern recognition.

Real AI value in security comes from automating analysis that previously required human expertise. Not replacing security teams, but giving them better tools to understand what's happening in their applications.

Building Security That Scales

The companies that get API security right don't start with tools. They start with principles. Security considerations get built into application design from the beginning. Security teams work closely with engineering throughout the development lifecycle.

This approach doesn't require massive budgets. It requires different thinking. Security becomes part of application architecture, rather than something bolted on afterward.

"Understanding that security done right from the beginning will save costs on the back end," Medrano notes. "It's not a matter of slowing down development. It's being conscious of what the threats might look like and how you address them directly into the application."

The organizations that will survive the next wave of API attacks aren't those with the most security tools. They're the ones that understand security as a fundamental part of application design.

Securing Your Node.js Application: A Comprehensive Guide by Sekurno

Tue, 14 Jan 2025 10:59:24 +0000

In today's digital landscape, securing your Node.js application is paramount. Vulnerabilities can lead to unauthorized access, data breaches, and loss of user trust. This guide condenses key security concepts and practices aligned with the OWASP Web Security Testing Guide (WSTG) to help you fortify your application.

Securing Your Node.js App: Information Gathering (WSTG-INFO)

Information Gathering is often the first step an attacker takes to learn more about your application. The more information they can collect, the easier it becomes for them to identify and exploit vulnerabilities.

Typical Express.js Server Configuration and Fingerprinting
By default, Express.js includes settings that can inadvertently reveal information about your server. A common example is the X-Powered-By HTTP header, which indicates that your application is using Express.

Example Vulnerable Code:

            const express = require('express');
const app = express();

// Your routes here

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

In this setup, every HTTP response includes the X-Powered-By: Express header.

Issue:

Fingerprinting: Attackers can use this header to determine the technologies you're using. Knowing you're running Express allows them to tailor attacks to known vulnerabilities in specific versions of Express or Node.js.

Mitigation: Disable this header to make it harder for attackers to fingerprint your server.

Improved Code:

    const express = require('express');
const app = express();

// Disable the X-Powered-By header
app.disable('x-powered-by');

// Your routes here

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

Enhanced Mitigation with Helmet:

A better approach is to use the helmet middleware, which sets various HTTP headers to improve your app's security.

const express = require('express');
const helmet = require('helmet');
const app = express();

// Use Helmet to secure headers
app.use(helmet());

// Your routes here

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

Why Use Helmet?

Comprehensive Security Headers: Helmet sets multiple HTTP headers that help protect your app from well-known web vulnerabilities.

Ease of Use: With just one line, you enhance your application's security posture significantly.

Configuration & Deployment Management Testing (WSTG-CONF)

Configuration and deployment management are critical aspects of application security. Misconfigurations can serve as open doors for attackers.

Running in Development Mode in Production
Running your application in development mode on a production server can expose detailed error messages and stack traces.

Example Vulnerable Code:

// app.js
const express = require('express');
const app = express();

// Error handling middleware
app.use((err, req, res, next) => {
  res.status(500).send(err.stack); // Sends stack trace to the client
});

// Your routes here

app.listen(3000);

In this setup, detailed error messages are sent to the client.

Issue:

Information Leakage: Detailed error messages and stack traces can reveal sensitive information about your application's structure, dependencies, and file paths.

Facilitates Exploitation: Attackers can use this information to identify potential vulnerabilities and craft targeted attacks.

Mitigation: Set NODE_ENV to 'production' and use generic error messages in production.

Improved Code:

// app.js
const express = require('express');
const app = express();

// Your routes here

// Error handling middleware
if (app.get('env') === 'production') {
  // Production error handler
  app.use((err, req, res, next) => {
    // Log the error internally
    console.error(err);
    res.status(500).send('An unexpected error occurred.');
  });
} else {
  // Development error handler (with stack trace)
  app.use((err, req, res, next) => {
    res.status(500).send(`<pre>${err.stack}</pre>`);
  });
}

app.listen(3000);

**Best Practices:**

Set Environment Variables Correctly: Ensure that NODE_ENV is set to 'production' in your production environment.

Internal Logging: Log errors internally for debugging purposes without exposing details to the end-user.

Using Default or Weak Credentials
Using default or weak credentials, such as a simple secret key for signing JSON Web Tokens (JWTs), is a common security mistake.

Example Vulnerable Code:

const express = require('express');
const jwt = require('jsonwebtoken');
const app = express();

// Weak secret key
const SECRET_KEY = 'secret';

app.post('/login', (req, res) => {
  // Authenticate user (authentication logic not shown)
  const userId = req.body.userId;

  // Sign the JWT with a weak secret
  const token = jwt.sign({ userId }, SECRET_KEY);
  res.json({ token });
});

app.get('/protected', (req, res) => {
  const token = req.headers['authorization'];

  try {
    // Verify the token using the weak secret
    const decoded = jwt.verify(token, SECRET_KEY);
    res.send('Access granted to protected data');
  } catch (err) {
    res.status(401).send('Unauthorized');
  }
});

app.listen(3000, () => {
  console.log('Server started on port 3000');
});

Issue:

Weak Secret Key: Using a simple or common string like 'secret' makes it easy for attackers to guess or brute-force the key.

Hard-Coded Secrets: Storing secrets directly in your code increases the risk of exposure if your codebase is compromised.

Token Forgery: Attackers who know your secret key can forge valid JWTs, gaining unauthorized access.

Mitigation: Use a strong, secure secret key and store it securely.

Improved Code:

// Secure secret key from environment variables
const SECRET_KEY = process.env.JWT_SECRET;

if (!SECRET_KEY) {
  throw new Error('JWT_SECRET environment variable is not set.');
}

app.post('/login', (req, res) => {
  // Authenticate user
  const userId = req.body.userId;

  // Sign the JWT with the secure secret
  const token = jwt.sign({ userId }, SECRET_KEY, { expiresIn: '1h' });
  res.json({ token });
});

Best Practices:

Environment Variables: Do not commit secrets to version control. Use environment variables or configuration files that are not checked into source control.

Rotate Secrets: Implement a process to rotate secrets periodically.

Validate Configuration: Ensure that all required environment variables are set during application startup.

Identity Management Testing (WSTG-IDNT)
Identity management is crucial for protecting user accounts and preventing unauthorized access.

Weak Username Policies and Account Enumeration
Allowing weak usernames and providing specific error messages can lead to account enumeration attacks.

Example Vulnerable Code:

// User registration without username validation
app.post('/register', async (req, res) => {
  const { username, password } = req.body;
  // Proceed without validating the username
  const user = new User({ username, password });
  await user.save();
  res.send('User registered successfully');
});

Issue:

Weak Usernames: Allowing short or simple usernames increases the risk of account compromise.

Account Enumeration: Specific error messages can help attackers determine valid usernames.

Mitigation: Implement username validation and use generic error messages.

Improved Code:

const { body, validationResult } = require('express-validator');

app.post(
  '/register',
  body('username')
    .isAlphanumeric()
    .isLength({ min: 5 })
    .withMessage('Username must be at least 5 characters and alphanumeric'),
  async (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).send('Registration failed');
    }
    // Proceed with registration
  }
);

Explanation:

Username Validation: Ensures usernames meet specific criteria, reducing weak entries.

Generic Error Messages: Prevent attackers from identifying valid usernames through error responses.

Authentication Testing (WSTG-ATHN)
Authentication mechanisms are vital for verifying user identities and preventing unauthorized access.

Brute-Force Attacks on Passwords and 2FA
Lack of protections allows attackers to guess passwords or 2FA codes through repeated attempts.

Example Vulnerable Code:

// Login route without rate limiting
app.post('/login', (req, res) => {
  // Authentication logic
  res.send('Logged in successfully');
});

Issue:

Unlimited Login Attempts: Attackers can repeatedly try different passwords or 2FA codes.

Weak 2FA Implementation: Static or predictable 2FA codes are vulnerable.

Mitigation: Implement rate limiting and enhance 2FA security.

Improved Code:

const rateLimit = require('express-rate-limit');

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5, // Limit each IP to 5 login attempts per windowMs
  message: 'Too many login attempts. Please try again later.',
});

app.post('/login', loginLimiter, (req, res) => {
  // Login logic
});

Additional Measures:

Use CAPTCHA After Failed Attempts: Introduce CAPTCHA after several failed login attempts to verify human users.

Employ TOTP for 2FA: Use time-based one-time passwords for dynamic and secure 2FA codes.

Explanation:

Rate Limiting: Reduces automated attack risks by limiting login attempts.

Enhanced 2FA: Time-based codes improve security over static codes.

Authorization Testing (WSTG-ATHZ)
Authorization ensures users access only the resources they are permitted to use, preventing unauthorized actions.

Insecure Direct Object References (IDOR)
Users can access unauthorized resources by manipulating identifiers in requests.

Example Vulnerable Code:

// Fetching an order without checking ownership
app.get('/orders/:orderId', async (req, res) => {
  const order = await Order.findById(req.params.orderId);
  res.json(order);
});

Issue:

Unauthorized Access: Users can access data they shouldn't by modifying the orderId parameter.

Mitigation: Validate resource ownership before providing access.

Improved Code:

app.get('/orders/:orderId', isAuthenticated, async (req, res) => {
  const order = await Order.findOne({
    _id: req.params.orderId,
    userId: req.user.id,
  });
  if (!order) {
    return res.status(404).send('Order not found or access denied');
  }
  res.json(order);
});

Explanation:

Ownership Verification: Ensures that the requested resource belongs to the authenticated user.

Access Control: Prevents users from accessing others' data by manipulating request parameters.

Session Management Testing (WSTG-SESS)
Session management is critical for maintaining user state and ensuring secure interactions.

Tokens Without Expiration Time
Tokens that never expire pose a security risk if they are compromised.

Example Vulnerable Code:

function generateToken(user) {
  return jwt.sign({ userId: user.id }, process.env.JWT_SECRET);
}

Issue:

Persistent Tokens: Tokens without expiration remain valid indefinitely, increasing the window of opportunity for misuse.

Mitigation: Set an expiration time on tokens.

Improved Code:

function generateToken(user) {
  return jwt.sign({ userId: user.id }, process.env.JWT_SECRET, {
    expiresIn: '1h', // Token expires in 1 hour
  });
}

Explanation:

Token Expiration: Limits the validity period, reducing the risk if a token is compromised.

Security Best Practice: Regular token renewal enhances overall security.

Insecure Token Storage
Storing tokens in localStorage exposes them to cross-site scripting (XSS) attacks.

Example Vulnerable Code:

// Storing token in localStorage
localStorage.setItem('authToken', token);

Issue:

Client-Side Exposure: Malicious scripts can access localStorage, stealing tokens and hijacking sessions.

Mitigation: Use HTTP-only cookies to store tokens securely.

Improved Code:

// Set token in an HTTP-only cookie
res.cookie('token', token, {
  httpOnly: true,   // Not accessible via JavaScript
  secure: true,     // Only sent over HTTPS
  sameSite: 'Strict', // Protects against CSRF
});

Explanation:

HTTP-only Cookies: Inaccessible to JavaScript, mitigating XSS risks.

Secure and SameSite Flags: Enhance protection against man-in-the-middle and cross-site request forgery attacks.

Input Validation Testing (WSTG-INPV)
Input validation ensures that user-provided data is safe and expected, preventing injection attacks.

Lack of Input Validation
Accepting and processing user input without validation can lead to vulnerabilities.

Example Vulnerable Code:

// Search endpoint without input validation
app.get('/search', (req, res) => {
  const query = req.query.q;
  // Use query directly in database operation
  const results = database.search(query);
  res.json(results);
});

Issue:

Injection Attacks: Unvalidated input can lead to SQL injection, NoSQL injection, or other code injection attacks.

Mitigation: Validate and sanitize all user inputs.

Improved Code:

const { query, validationResult } = require('express-validator');

app.get(
  '/search',
  query('q').trim().escape().notEmpty().withMessage('Query is required'),
  (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).send('Invalid search query');
    }
    const sanitizedQuery = req.query.q;
    // Use parameterized queries or ORM methods
    const results = database.search(sanitizedQuery);
    res.json(results);
  }
);

Explanation:

Input Validation: Checks that input meets expected criteria.

Input Sanitization: Removes or escapes potentially harmful characters.

Secure Database Queries: Using parameterized queries prevents injection attacks.

Testing for Error Handling (WSTG-ERRH)
Proper error handling avoids disclosing sensitive information and improves user experience.

Exposing Sensitive Error Information
Detailed error messages can reveal system internals to attackers.

Example Vulnerable Code:

app.use((err, req, res, next) => {
  res.status(500).send(err.stack); // Sends stack trace to the client
});

Issue:

Information Disclosure: Attackers can gain insights into your application's structure and potential vulnerabilities.

Mitigation: Use generic error messages and log detailed errors internally.

Improved Code:

app.use((err, req, res, next) => {
  console.error('Unhandled error:', err); // Log the error internally
  res.status(500).send('An unexpected error occurred');
});

Explanation:

Internal Logging: Keeps detailed error information secure.

User-Friendly Messages: Provides a generic message without revealing sensitive details.

Testing for Weak Cryptography (WSTG-CRYP)
Cryptography protects sensitive data; using weak cryptographic practices undermines security.

Using Insecure Hashing Algorithms
Hashing passwords with outdated algorithms is insecure.

Example Vulnerable Code:

const crypto = require('crypto');

function hashPassword(password) {
  return crypto.createHash('md5').update(password).digest('hex');
}

Issue:

Weak Hashing: Algorithms like MD5 and SHA-1 are vulnerable to collision attacks and should not be used for password hashing.

Mitigation: Use a strong hashing algorithm designed for passwords.

Improved Code:

const bcrypt = require('bcrypt');

async function hashPassword(password) {
  const saltRounds = 12;
  return await bcrypt.hash(password, saltRounds);
}

Explanation:

Bcrypt: A robust hashing function that incorporates salting and multiple rounds of hashing.

Password Security: Makes it computationally infeasible for attackers to reverse-engineer passwords.

Hardcoding Secret Keys
Storing secrets directly in code increases the risk of exposure.

Example Vulnerable Code:

// Hardcoded secret key
const API_SECRET = 'mySuperSecretKey123!';

Issue:

Secret Exposure: If the codebase is compromised, hardcoded secrets can be easily extracted.

Mitigation: Store secrets in environment variables or secure configuration files.

Improved Code:

const API_SECRET = process.env.API_SECRET;

if (!API_SECRET) {
  throw new Error('API_SECRET is not defined');
}

Explanation:

Environment Variables: Keep secrets out of the codebase and version control systems.

Security Practices: Reduces the risk of accidental exposure.

Business Logic Testing (WSTG-BUSL)
Business logic vulnerabilities occur when application flows can be manipulated in unintended ways.

Abuse of Bulk Operations
Unrestricted data operations can lead to performance issues or data leakage.

Example Vulnerable Code:

// Endpoint that exports all user data
app.get('/export-data', async (req, res) => {
  const data = await Data.find();
  res.json(data);
});

Issue:

Denial of Service (DoS): Large data exports can exhaust server resources.

Data Leakage: Unrestricted access may expose sens