Proof-Driven AppSec foundations

Why alert volume is not security

Most application security programs can tell you how many alerts they have. Far fewer can tell you which of those alerts an attacker can actually use, what each one affects, and whether the fix shipped. This course starts with that gap, because the rest of the platform is built to close it.

An alert count measures how many tools you run and how many rules they apply. It does not measure risk. Four problems explain the difference.

Tool sprawl

Teams usually add tools one category at a time: a static analyzer for code, a dependency checker, a secrets scanner, an infrastructure-as-code checker, a container image scanner. Each one has its own console, its own severity scale and its own output format. The same vulnerable dependency can appear in two or three of them under different names and severities, and nobody owns the merged view. Engineers end up reconciling exports instead of fixing code.

Plexicus brings scanner output into one finding format and deduplicates it, and the surviving finding keeps the worst severity of its duplicates. You can also import results from compatible third-party scanners (for example as SARIF) into the same workflow. Module 3 covers engines, coverage and the exact deduplication rule.

Noise

Consider a static analysis result titled “possible SQL injection in login handler”. It might be a real, exploitable flaw in the login form, where the username flows straight into a query string. It might also be a query built from a constant in a test helper that no user input can ever reach. Both arrive with the same label and often the same severity.

When most alerts turn out to be the second kind, developers learn to skim the list, and the real ones get skimmed too. What separates the two cases is evidence: whether a path exists from attacker-controlled input to the vulnerable code, whether the code is reachable at all, and whether a second, independent check confirms the result.

The remediation bottleneck

Detecting is not fixing. Every open finding is work your team still owes. Finding a new issue is cheap. Fixing it takes a developer who understands the code, a change that does not break anything, a review and a merge. If the queue grows faster than the team can close it, more detection makes the backlog bigger without making the application any safer. The real bottleneck is context and reviewable changes, not a shortage of alerts.

Posture blindness

Try to answer these questions from a raw alert list. Which three repositories carry the most exploitable risk? Are you closing findings faster than you create them? How long does a critical finding stay open? A growing pile of alerts cannot answer any of them. Leadership sees a number that only goes up, and the next audit finds the same issues again.

Scanning more often has the same limit. A nightly scan that reports the same unfixed SQL injection for a month measures activity, not progress. Scan frequency tells you how often you looked, not whether anything got safer.

The Plexicus Dashboard follows the same idea: its totals count open work only (module 2). The CISO tab shows a Risk Posture Score, New vs Fixed and Top Risky Repositories. The DevSecOps tab adds reachability, finding age and remediation velocity.

The Proof-Driven loop: Validate, Understand, Remediate

Plexicus calls its approach Proof-Driven AppSec: know what is real, understand what it affects, fix it with evidence. The approach has three steps, and each step is a product.

Step	Product	Question it answers	What you get
Validate	AI Swarm Pentest	Can this actually be exploited within the authorized scope?	Verified findings with reproducible evidence, a priority and a documented handover
Understand	Deep Code Analysis	What code, data and business flow does it affect, and can an attacker reach it?	The affected flow, its reachability and exposure, a CWE weakness class and a priority
Remediate	Remediation	What change closes it, and did the change work?	A reviewer-ready change with the evidence attached, delivered through your pull request workflow, plus verification re-tests where configured

Validate with AI Swarm Pentest

AI Swarm Pentest is a scoped, authorized engagement against an application, API, source code or test environment. Coordinated AI checks map the attack surface, form hypotheses and test paths, and a second pass independently confirms each finding before it is marked verified. It is not a signature scanner and it is not a security chatbot. In the product it appears as AI Pentest under the Pentest section. Module 6 covers it in depth.

Understand with Deep Code Analysis

A static analysis rule can flag a pattern, and a language model can explain code. Neither establishes how a weakness affects your application. Deep Code Analysis connects a finding to code, data flow and business impact. For each finding you get the affected flow (source, propagation and sink), whether an attacker can reach it and from where (reachability and internet exposure), and a weakness class mapped to CWE and OWASP. Module 5 covers it.

Remediate with Remediation

Once a finding is verified, Remediation prepares the context and a suggested change as a reviewer-ready diff. Your team reviews it and decides whether to merge. When the pull request is merged, Plexicus marks the finding Fixed. Depending on your plan and configuration, a verification test can check the fix before the pull request is opened, and for a pentest finding you can rescan the assessment to check that the path is closed. Module 7 covers the workflow.

Example

One finding through the loop: an insecure direct object reference (IDOR) in an invoice API

Validate. The pentest shows that a signed-in customer can call GET /api/invoices/1042, change the ID, and receive another customer’s invoice. A second pass reproduces it with a separate request, so the finding is verified.
Understand. Deep Code Analysis traces the request to the invoice handler. It shows that the handler loads the invoice by ID without checking who owns it, that billing details are exposed, and that any authenticated customer can trigger it.
Remediate. Remediation prepares a diff for the invoice handler that adds the ownership check, with the evidence and rationale attached. A developer reviews and merges it, and a rescan of the assessment against the same URL confirms that the cross-customer request now fails.

Where XBOM and Plexicus Automation fit

Two products work alongside the loop rather than inside one step:

XBOM is one inventory of software components (SBOM), cryptographic assets (CBOM) and AI models (AIBOM), with VEX statements that record whether a known vulnerability affects you. It answers questions such as “where do we ship the vulnerable version of this library?” and produces evidence for audits. Module 8 covers it.
Plexicus Automation routes findings to fixes, tickets, approvals and notifications, for example when a finding is created, enriched or reopened. Only admins can activate a flow. Module 9 covers it.

SAST, SCA, infrastructure-as-code checks, secrets detection and imported scanner results provide supporting coverage. They supply signals that feed the loop. They do not replace it.

The evidence standard and its guardrails

The rule behind every Plexicus deliverable fits in one line: no reproducible proof, no verified finding. This lesson covers what counts as proof, how a signal becomes a verified finding, and the four guardrails that keep an engagement inside agreed limits.

Reproducible proof

Every finding in an AI Swarm Pentest deliverable carries evidence that someone else can reproduce: the request, the response, the steps and the impact that was demonstrated. “The scanner said so” is not proof. Pentest findings in the product can include a replay proof of concept, such as a cURL command, a shell script or a HAR capture. It is shown exactly as recorded and is not re-run from your browser.

Independent verification

A signal does not become a verified finding because one check says so. A second pass has to confirm the observed behavior independently.

Stage	What it means	What happens next
Candidate finding	A hypothesis produced a signal with technical context	It goes to independent verification
Verified finding	A second pass reproduced the result	It enters the deliverable with impact and priority
Not confirmed	The second pass could not reproduce it	It is marked unverified or discarded, never reported as verified

Apply the same discipline when you triage scanner results. The finding detail view shows the scanner’s severity next to the AI-validated severity (“Severity — scanner vs AI”). It also labels each step of a dataflow trace by origin, such as Scanner dataflow or AI-verified. Treat any step marked AI-inferred (unverified) as a lead to check, not as proof (module 5 explains how traces are verified).

The four guardrails

On an AI Swarm Pentest engagement, the evidence standard is backed by four guardrails. They are the same four you will see on the public AI Swarm Pentest page, and module 6 applies them in depth.

Guardrail	What it means for you
Scope agreed in writing	The target (an application, API, source code or test environment), the test access and the rules of engagement are confirmed before work starts. Plexicus does not act outside that scope.
Traceable evidence	Supporting evidence stays attached to the finding it explains.
Engagement limits	Time, resources and access are bounded, so each run stays controlled.
Human decision	Your team keeps final approval and control of every change. Plexicus makes no automatic production changes.

How the product enforces scope

You cannot launch an AI Pentest until you have proven that you own the target. For one application you prove it with a token in an HTML meta tag or a file under /.well-known/. For a whole domain you prove it with a DNS TXT record. Accepting terms of service does not count as proof. In a new assessment, “Destructive actions” is preselected as out of scope, and the wizard recommends testing staging rather than production.

Human decision and merge control

AI automates the repetitive work of exploration, correlation and reproduction. Your team keeps the context, the supervision and the final decision. In the product, a person’s “Mark as false positive” decision is authoritative, and later AI passes do not override it. AI-prepared fixes come with a note asking the reviewer to validate the change.

Plexicus never modifies production. It delivers reviewable proposals only, as pull requests or separate patch files. The AI fix agent edits an isolated clone of your repository. Plexicus pushes the change only to a new branch and opens a pull request against your base branch, and it never merges that pull request. Merging is always your team’s decision in your own source control.

A map of the platform and who uses it

The main sidebar takes you to Dashboard, Assets, Pentest, Findings, XBOM, the Automations page and Settings. Docs and Support sit at the bottom. Press ⌘K (Ctrl+K on Windows and Linux) to open a command palette and jump straight to any section.

Area	What you do there	Who uses it most
Dashboard	Track posture through the CISO, DevSecOps, Compliance, Developer and Custom tabs, filtered by date range and repository	Security leads, security engineers, developers
Assets	Manage connected repositories in the Repo Scan tab: add repositories, follow scans, re-scan. The Registry Audit and Cloud Assessment tabs are available depending on your plan	Security engineers, platform owners
Pentest	Create AI Pentest assessments, verify target ownership, watch runs and open their results	Security engineers
Findings	Triage findings across the Repo, SCM, Cloud, Registry and App Pentest tabs. Open a finding to review evidence, create a ticket or start remediation	Security engineers, developers
XBOM	Browse the Software (SBOM), Cryptography (CBOM) and AI Models (AIBOM) inventories, set VEX statements and export	Security engineers, compliance, platform owners
Automations	Build flows that route findings to fixes, tickets and approvals	Admins build and activate flows
Settings	Organization (team, roles, ownership verification), Configuration (integrations, platform options, billing) and My Account (account details, authentication, tokens)	Admins and platform owners, plus everyone for their own account

Three kinds of users

Security engineers (AppSec and DevSecOps) triage findings, configure scans, run AI Pentest assessments and hand verified work to developers.
Developers work through the findings assigned to them, review AI-prepared fixes and open pull requests. Many prefer to do this from the IDE or terminal, which module 9 covers.
Platform owners deploy and operate Plexicus, connect source control and identity providers, and manage organization settings.

Built-in roles at a high level

Role	What it is for
Admin	Full organization administration: team, roles, settings, integrations, billing and the audit log. Admins can also generate remediations and open pull requests.
Cyberoper	The security operator role. Triages findings, marks false positives, generates remediations and uses Send to Dev Team to assign work. By default it does not open pull requests.
Developer	Works on the findings assigned to them and opens pull requests for fixes that are Ready to Fix.

The split is deliberate. With the default roles, the person who prepares a fix and the person who proposes it to the codebase can be different people. A Cyberoper generates and reviews the change, and a Developer opens the pull request. Depending on your plan, admins can also create custom roles under Settings Roles . Built-in roles cannot be renamed or deleted. Module 10 covers roles, SSO and the audit log in detail.

Deployment and trust basics

Plexicus runs as EU SaaS or self-hosted, and air-gapped is a variant of self-hosted. The product is the same in each, and only the hosting and network boundaries change.

Option	Where it runs	When to choose it
EU SaaS (default)	Plexicus-hosted at app.plexicus.ai, operated under an EU data-residency commitment (see trust.plexicus.ai)	Most teams. No infrastructure to manage, and updates are automatic
Self-hosted	Your own Kubernetes cluster, on premises or in a cloud account you control, installed with the official Helm chart	Strict data-residency, compliance or network-isolation requirements
Air-gapped (self-hosted variant)	The self-hosted Helm installation, with images mirrored to an internal registry and your own internal certificate issuer	Clusters with no public internet access or with tight egress controls

What “self-hosted” means

Self-hosted and on-premises are the same product, chart and license, and a self-hosted deployment sends no telemetry, analytics or feedback data outside your cluster. Features that depend on Plexicus’s commercial services, such as billing, are turned off, and only the integrations you configure yourself, such as your source control and your AI provider, talk to external systems. Module 10 covers Helm, air-gapped installs and backups.

Your code and AI

Customer code is not used to train AI models.
Plexicus SaaS is operated under an EU data-residency commitment (see trust.plexicus.ai). The legal entity, PLEXICUS, S.L., is based in Bilbao, Spain, under EU jurisdiction.
AI features send the relevant code context to the configured model endpoint. That is Plexicus-managed models by default or, depending on your plan, your own AI provider endpoint, configured under Settings BYOAI .

Trust and evidence

Plexicus holds a SOC 2 Type II certification. An independent firm pentests the platform every year. The SOC 2 report, a DPA template, the penetration test summary and security questionnaire responses are self-serve on the trust portal at trust.plexicus.ai. Report a vulnerability in Plexicus itself to info@plexicus.ai.

Be precise when you talk about compliance. Plexicus does not make your organization compliant with NIS2, DORA Article 28, the CRA or the EU AI Act. It maps findings to the frameworks you select, such as NIS2, DORA and the CRA, in the Dashboard’s Compliance tab, and XBOM attestations can be scored against profiles such as the EU CRA and the EU AI Act. Your auditors then assess that evidence. Module 8 covers it in detail.

Key takeaways

Alert volume measures tool output, not risk. Tool sprawl, noise, the remediation bottleneck and posture blindness are what keep teams busy without making them safer.
Proof-Driven AppSec is a loop: Validate with AI Swarm Pentest, Understand with Deep Code Analysis, and Remediate with Remediation. XBOM and Plexicus Automation work alongside it.
No reproducible proof, no verified finding. A result a second pass cannot reproduce is marked unverified or discarded.
On an AI Swarm Pentest engagement, four guardrails apply: scope agreed in writing, traceable evidence, engagement limits and human decision. Plexicus makes no automatic production changes, and your team always keeps merge control.
The sidebar takes you to Dashboard, Assets, Pentest, Findings, XBOM, the Automations page and Settings. The three built-in roles, Admin, Cyberoper and Developer, split the duties.
EU SaaS is the default, and self-hosted Helm and air-gapped installs run the same product. Customer code is not used for AI training, and Plexicus holds SOC 2 Type II while producing evidence, not compliance, for your frameworks.