Pixee 6.0: Findings that know your architecture

Release Notes · Enterprise Server 6.0 · September 2026

Your scanner knows what's vulnerable. It has no idea what's dangerous. Danger depends on where the code sits, what it's exposed to, and what it can reach, and none of that is in the scan.

Pixee 6.0 moves that judgment into the product.

The big idea: your findings now know your architecture.

Turn it on per repository, and Pixee builds a threat model from your code, re-ranks every finding against it, and chains the ones that matter into the attack paths an adversary would really walk. A year of work also went into the Resolution Center you already run and the enterprise controls to run it all in production.

What shipped in 6.0

• Threat models. A per-repo model built from your source, with a ten-dimension scorecard and finding overlays that re-rank your findings by real exposure.

• Exploit Chains. Validated multi-step attack paths composed from your already-triaged findings.

• Resolution Center. Threat-model context at every stage, plus Aikido (SAST), OWASP ZAP (DAST), and SCA on by default.

• Enterprise grade. SSO required, an in-cluster LLM gateway with your choice of provider, and one release that runs air-gapped or cloud-hosted.

Here's each piece, and how it works.

Threat models: your list, reordered by what's exposed

Start with the part you'll feel first.

Pixee reads your repo and builds a threat model from the code itself, rendered as three views: a narrative overview, an attack-surface map, and an adjudication view, with a control-to-threat coverage graph alongside. Every triaged finding then gets scored against that model, earning a priority from 0 to 100, a tier, and a one-line reason that names the exact element that moved it.

A SQL injection behind three layers of internal auth drops. The same bug on an unauthenticated endpoint that touches customer records climbs. A dozen alerts that all trace back to one exposed entry point collapse into a single problem.

The Resolution Center already clears up to 95% of false positives. Now the ones that survive are ordered by real exposure instead of a generic severity label. A long list becomes a short one, and the short one is right.

Each model carries a ten-dimension scorecard: attack surface, blast radius, authentication, secrets, dependency risk, and five more. Every dimension is scored against its own rubric, with the evidence behind the score shown in the UI. A first model typically builds in five to ten minutes.

It also stays current. When you merge to your default branch, an agent decides whether the change warrants a new model and records why when it doesn't. It updates on its own judgment rather than on a fixed schedule, and it's rolling out in stages now.

Exploit Chains: two mediums, one account takeover

A path traversal is a medium. An on-disk JWT signing key is a medium. Neither one pages you at 2am.

Put them together and they forge an admin token. That is a full account takeover, assembled from two findings your stack filed under "get to it later."

Exploit Chains finds those combinations. On demand, at the repository level, it takes your already-triaged findings and walks them into multi-step attack paths, starting from the repo's own threat model. The agent opens the code and confirms each hop is genuinely reachable before it links the next one, then draws the path as a diagram with a written narrative.

That example comes from our own benchmark suite. So does another that crosses SCA and SAST, a PyYAML CVE plus an unsafe yaml.load call that composes into remote code execution, which is the kind of path no single scanner reports.

When there is no chain to find, Exploit Chains says so.

Zero chains is a real result. We would rather tell you an attacker can't compose your findings than invent one to look busy.

The Resolution Center got the same context

Findings still arrive from the tools you already run, and the Resolution Center is still where they get triaged, prioritized, and fixed. In 6.0, every stage of that pipeline reads the threat model.

Triage now weighs your architecture, so severity tracks exposure. Externalized config references stop getting flagged as hardcoded credentials. Blocked and excluded findings explain themselves in the drawer instead of going quiet.

On the fix side:

• Bulk fixes describe what they changed in the pull request title and body, so a reviewer can approve without reverse-engineering the diff.

• Smart Fix untangles conflicting version requirements across a dependency tree and no longer rewrites your lockfiles.

• New scanner sources. Aikido joins as a SAST source and OWASP ZAP as a new DAST source. DAST results now get labeled as DAST, instead of lumped in with SAST.

• SCA and transitive analysis are on by default.

76% of the fixes Pixee opens get merged. Threat modeling changes which findings you look at; the Resolution Center is what closes them.

Enterprise grade: ready for how you run software

If you run Pixee unauthenticated today, your current version keeps running — there's no forced cutover. 6.0 itself requires enterprise SSO. The unauthenticated mode is gone, with Okta and Oracle Identity Domains federation through a common framework, and roles enforced in the product from your IdP's claims. When you're ready to configure an identity provider and upgrade, the guide walks through it.

All model traffic now routes through an in-cluster LLM gateway, internal-only, with AWS Bedrock alongside OpenAI, Anthropic, and Azure. Per-request spend lands in your own database, and repeated analysis of the same commit reuses a cached response instead of paying a provider twice. You pick the model, you see the cost, and nothing routes through a vendor's console.

The rest is the quiet list that keeps a security tool deployable:

• Reporting inside your deployment

• Multiple instances of the same scanner (several Sonar servers, several Snyk orgs) managed in-product with live health indicators

• One release that runs air-gapped or cloud-hosted, on embedded or external Postgres and object storage

We also spent real time this year hardening Pixee itself, tightening privilege boundaries, reducing the sensitive data that reaches logs and diagnostics, and cleaning up secret handling. Your security team can walk through the specifics with ours.

Threat models and Exploit Chains are included in your plan and off by default. If you already run Pixee, turn them on per repository whenever you're ready. If you don't yet, see it on your own code.

Context is the difference between a list and a plan.