Pixee 6.1: Pixee now looks for vulnerabilities on its own

Release Notes · Enterprise Server 6.1 · October 2026

Pixee 6.1 is out. The biggest change is that Pixee now also looks for vulnerabilities in your code directly, without waiting for one of your scanners to flag something first. It plans each search from the repository's threat model, the one it has used since 6.0 to rank what your scanners send. Whatever it finds can go straight into the same triage and fix, down to the pull request.

It's aimed at the bugs rule-based scanners are worst at, the ones that exist only because of how your application handles who can see what, like an API route that returns an account's invoices without checking who's asking. That kind of bug usually turns up in a pen test, after the scans have come back clean. Your scanners stay the main feed.

What's new in Pixee 6.1

• Pixee AI Scanner. Searches each repository for the kinds of weakness its threat model says are likely, and can hand what it finds straight to triage and fix.

• Contextual CVSS. Dependency findings get a second score, filled in from the repository's attack surface, so you can see which ones to work first. The original score stays beside it.

• Attack paths. A view in each threat model of who can reach what, and where a security control stands in the way.

• Security Posture. Every repository's threat model in one view, with a risk score per repository based on its threat model and how exposed it is.

• Resolution Center. Exploit Chains that say why a run found nothing, triage that notes business impact, fixes in review that no longer get swapped for a lower-rated one, and Black Duck Hub as a native SCA source.

• For the team that runs Pixee. More than one connection to the same Git provider or to any of six scanners, analyses that queue through load spikes instead of failing, single sign-out, and stricter webhook checks.

Your account team turns on the AI Scanner and Security Posture for your install, and the Detections tab and risk scores come with them. Scans run inside your Pixee instance, Pixee-hosted or self-hosted. Everything else is available as soon as you're on 6.1.

Pixee AI Scanner

A rule-based scanner's rules are written before it has seen your code, so unless your team writes custom rules, it's best at bugs that look the same in every codebase, like user input concatenated into a SQL query. Now picture that invoices route in code, taking an account ID and returning that account's invoices without ever checking that the account belongs to whoever is logged in. Nothing in that code calls a dangerous function.

That's why every AI Scanner run starts from the repository's threat model. If Pixee hasn't built one yet, the scan builds one first, using the same agent behind the threat-model tab, and saves it for next time. That makes a repository's first scan take longer.

The threat model records the repo's entry points, trust boundaries, security controls, and sensitive assets, and which kinds of weakness are likely given all of that. The scan builds its plan from those weakness classes and searches only for those. Each entry in the plan carries a brief: which entry points reach it, which controls already stand in front of it, what an attacker would gain, and what to confirm before reporting it.

Take the invoices route. If the threat model records it as a public entry point, the plan would include broken access control. The brief would name that route, note the session check in front of it, and ask whether anything ties the account ID to the person who's logged in. An agent then follows each brief through the code and reports what it finds, tied to specific lines.

When you start a scan, one toggle reads "Automatically triage and fix findings". Turn it on and Pixee triages each finding and proposes a fix for your developers to review. Leave it off to get the findings alone and choose what to analyze yourself. Either way, the results show up as a scan next to your other scans.

Scans run in the background with live progress, and their results are standard SARIF. Each repository's Detections tab also shows Opengrep rules generated from its threat model, which you can copy into your own pipeline.

Severity that reflects your repository

A CVSS base score describes a vulnerability in general. It can't tell you how exposed your repository is.

In 6.1, dependency findings get a second score, a contextual CVSS, with the environmental metrics filled in from the repository's attack surface. The contextual score shows in the findings grid and the SCA drawer, next to the base score, so you can see how much your repository's exposure moved it.

Attack paths

Each threat model now has an Attack paths view. It reads left to right: who can reach the system, through which entry points, which security controls stand in the way, which weaknesses are present, and what is at risk. A weakness that no control covers is marked as a coverage gap, so the places that need a control stand out.

Security Posture and repository risk scores

Security Posture rolls every repository's threat model into one view of your estate. The repositories page ranks repos by a risk score built from each threat model's scorecard and scaled by how reachable the repo is from an untrusted network. Confirmed findings don't count toward the score yet, so for now it tells you how exposed a repository is.

The Resolution Center

• Exploit Chains. They now show the search as it runs and explain why when they find nothing.

• Triage. It reads the threat model and now adds the business impact of a finding and notes where it could be part of an exploit chain.

• Fixes. A fix that's already in review is no longer replaced by a lower-rated one. Fixes also no longer add new source files.

• SCA. Black Duck Hub is now a native source, with its BDSA (Black Duck Security Advisory) solution used as upgrade guidance. The SCA drawer now shows the dependency graph and a CVE browser.

For the findings your scanners send, Pixee's 2025 customer cohort reached a 94% end-to-end resolution rate, from scanner finding to handled decision.

For the team that runs Pixee

• Sonar, Checkmarx, Veracode, Polaris, AppScan, Arnica, GitHub, GitLab, Bitbucket, and Azure DevOps connections can each be added more than once, managed in the product.

• When the analysis service is briefly saturated, new analyses wait their turn in the queue instead of failing.

• Single sign-out. Logging out at your identity provider ends the Pixee session.

• Source-control webhook deliveries that can't be verified are refused.

• Threshold alerting, and limits on how much log and trace data the install keeps.

We kept hardening Pixee, with tighter privilege boundaries on administrative operations, less sensitive data reaching logs and diagnostics, and changes to how secrets are handled. Specifics are available under NDA.

Where to start

Ask your account team to turn on the AI Scanner, and point its first run at a repository you know well, ideally one no scanner covers today, so you can check each finding against what you know.

If you don't run Pixee yet, see it on your own code.