Back to blog

Pragma Core for Dynamic AppSec Teams

· · 18 min read
Pragma Core for Dynamic AppSec Teams

Most application security teams still operate on a rhythm that was designed for a slower world: a scanner runs in the pipeline, a pentest happens once or twice a year, a report lands in an inbox, and everyone moves on until the next cycle. The problem is that the code does not wait for the cycle. It ships daily, dependencies rotate weekly, infrastructure drifts constantly, and attackers do not schedule themselves around your audit calendar. A dynamic AppSec team is one that has given up on the audit-calendar model entirely and treats security as a continuous, always-running function of engineering. Pragma Core is the platform built for exactly that team, and its one-line promise captures the shift precisely: your red team, running every day.

This is a presentation of what Pragma Core actually gives a dynamic AppSec team, written in two layers. The first part is for the people who decide whether to adopt a platform: what problem it solves, who benefits, and what changes on Monday morning. The second part is for the engineers and security operators who will live inside it every day: the module surface, how the AI agents reason, how the pieces connect across code, infrastructure, and adversary simulation. The article closes by looking at how these features fit into the operating model of a team that has stopped thinking in cycles and started thinking in continuous coverage.


Part I. Executive breakdown

What a dynamic AppSec team needs

Picture the security function of a company that ships continuously. Engineering merges dozens of pull requests a day across a dozen repositories. A new microservice appears on Tuesday. A base image picks up a fresh CVE overnight. A contractor spins up an internal host that nobody adds to the asset inventory. The classic AppSec response to all of this is a set of disconnected tools: a SAST scanner here, a dependency checker there, an annual external pentest bought from a consultancy, and a threat model that someone drew in a diagramming tool eighteen months ago and never touched again.

The gap is not that any single one of those tools is bad. The gap is that they do not share a brain. The scanner does not know what the pentest found. The dependency tracker cannot see how a vulnerable package is actually reached at runtime. The threat model does not update when the architecture changes. Between the tools sit the exact bugs that matter most: the ones about how input and state flow across functions, services, and trust boundaries, not the ones sitting on a single obviously-bad line.

A dynamic AppSec team needs three things a pile of point tools cannot give it. It needs continuity, so coverage does not lapse the moment a scan finishes. It needs context, so a finding in one module is enriched by everything the platform already knows about the codebase, the infrastructure, and the attack surface. And it needs depth on demand, so that when something looks fragile, an operator can push an investigation deeper instead of filing a ticket and waiting for next quarter's engagement. Pragma Core is built around those three needs.

Who this is for

Pragma Core is built by zer0day Technologies, a Romanian offensive-security firm, together with Expertware, a European IT-infrastructure consultancy. That pairing matters: it combines deep red-team knowledge with large-scale infrastructure experience, which is why the platform spans code, infrastructure, and adversary emulation rather than just source scanning. Here is who gets the most out of it.

Team or role What Pragma Core gives them
AppSec engineers Continuous SAST, SCA, and DAST with AI-confirmed findings, so triage time goes to real bugs, not false positives
Security leads / CISOs A unified workspace across code, infra, and adversary emulation, plus SBOM and compliance exports that answer audit questions in minutes
Platform / DevSecOps teams Native repo integration and daily CI/CD pipeline scanning across five CI platforms, with findings tied to repo, branch, and commit
Red and purple teams Agentic internal and external pentests and MITRE ATT&CK-aligned breach-and-attack simulation, running on a rolling cadence
Engineering managers Code Map call graphs, threat models, and code-quality signals that make architectural risk legible without reading every diff

The common thread is that none of these people want a new silo. They want one place where a continuous stream of findings arrives already contextualized, already deduplicated against what the platform knows, and ready to act on. The number that should frame the decision is simple: a team running annual pentests is blind for roughly 360 days a year. A dynamic team closes that window to zero.

Why this matters beyond tooling

The deeper reason to care is that the economics of attack have shifted. AI has lowered the cost of finding and chaining vulnerabilities for the attacker just as much as for the defender. When the offensive side can reason over your attack surface continuously, a defensive posture that reasons over it once a year is not a fair fight. The response is not to buy more scanners. It is to change the cadence: to run the offensive analysis on the same clock the attacker does, which is all the time.

This is the pattern that shows up across the whole industry, not just in one product category. Bugs increasingly live in the relationships between components: a short-circuit that skips a verifier, a value that flows from a low-trust entry point into a high-privilege consumer, a dependency that is only exploitable given a specific runtime path. Point tools that examine one function or one endpoint in isolation structurally cannot see these. A platform that reasons across the whole graph, continuously, can. That is the class of problem a dynamic AppSec team exists to catch, and it is the class Pragma Core is designed around.

Recommended actions

  1. Connect your repositories first. Pragma Core integrates with GitHub, GitLab, and Azure DevOps in minutes, and continuous scanning starts immediately. Start with the repositories that carry the most sensitive logic, not the easiest ones.
  2. Turn on the continuous modules and let them run. SAST, SCA, dependency tracking, and CI/CD pipeline scanning are the always-on baseline. Give them a full cycle before triaging, so the AI has context to confirm findings and suppress noise.
  3. Generate an SBOM per repository. Export CycloneDX inventories early. They answer the "which version of what do we run, and where" question that otherwise stalls every incident response.
  4. Schedule the offensive modules on a rolling cadence. Move external and internal pentests and adversary emulation from annual events to a recurring schedule so the coverage never lapses.
  5. Reserve capacity for human-guided investigations. When a module flags something that feels architecturally fragile, drive an AI Security Research investigation into it rather than closing the ticket. This is where the deep bugs get caught.
  6. Adopt the unified workspace as the source of truth. Route findings, ownership, and remediation through the single workspace instead of scattering them across separate tool dashboards.

Part II. Technical breakdown

The architecture: one workspace, three domains

Pragma Core is organized as a single workspace that spans three security domains that are usually sold and operated separately: application security, infrastructure security, and adversary emulation. The design decision underneath is that these three should share context. A weakness found in code should inform the internal pentest. An exposed service found by the external pentest should inform which repositories deserve deeper scanning. An ATT&CK technique that succeeds in a simulation should point back at the control that failed. When the three run in one workspace, findings from one domain enrich the others instead of sitting in three disconnected reports.

The engine underneath is AI-driven and continuous. Rather than a fixed ruleset that runs to completion and stops, Pragma Core runs autonomous agents that reason over the codebase and the attack surface, ask follow-up questions, and confirm findings before they surface. That is what lets it target the flow-and-state bugs that classical single-function analysis misses, and it is what keeps false positives low enough that a team will actually trust the queue.

Application security: the ten-module surface

The application-security domain is where a dynamic AppSec team spends most of its day, and it is the deepest part of the platform. It is worth walking the full surface, because the value is in how the modules combine.

The point is not the length of the list. The point is that these run continuously and in the same workspace, so a vulnerable dependency surfaced by SCA can be traced through the Code Map to the exact function that reaches it, checked against the Threat Model for whether it crosses a trust boundary, and handed to AI Security Research if the reachability is non-obvious. That chain is a single motion inside Pragma Core. Across separate tools it is a week of manual correlation.

A worked example: from flagged line to confirmed chain

Consider how a dynamic team actually uses this. A pull request merges a change to a payments service. Here is the shape of what the platform does with it, expressed as the reasoning trail an operator sees.

# workspace: acme-payments · trigger: on_push (commit 4f2a9c1)
[sast]    flagged  chargeRefund()   → user-controlled amount reaches ledger write
[codemap] traced   entrypoint POST /refunds → chargeRefund → applyLedgerDelta
[sca]     context  ledger-lib 3.4.1 → known integer-handling advisory on delta path
[research] question "is applyLedgerDelta reachable without the amount cap check?"
[research] answer   yes: cap check is bypassed when refund.currency == "internal"
→ verdict:  confirmed logic bug · authorization gate skipped by type exemption
→ evidence: request trace + call path saved · owner: payments · severity high

No single line in that trail is the whole bug. SAST flags a value it does not like. Code Map proves the value actually reaches a sensitive write. SCA adds that the library on the path has a relevant advisory. The research agent asks the one question that matters, whether the cap check is truly reached for every input, and finds the type-based exemption that skips it. That is the flow-and-state class of bug, and it is caught because the modules share context rather than reporting in isolation.

Infrastructure security and external surface

Application security is only half of a real attack surface. Pragma Core carries two infrastructure modules that a dynamic team schedules on a rolling cadence rather than buying as one-off engagements.

Because these live in the same workspace as the code modules, an exposed service the external pentest finds can point straight back at the repository that owns it, and a foothold the internal pentest models can be checked against the code that would run once an attacker reaches it.

Adversary emulation on the live ATT&CK matrix

The third domain is breach and attack simulation aligned with the live MITRE ATT&CK matrix. Instead of asking "do we have a control for technique X," a dynamic team runs the technique and watches whether it succeeds. Because the emulation is aligned with the live ATT&CK matrix rather than a frozen snapshot, coverage tracks the techniques attackers are actually using now. A technique that lands points directly at the detection or control that failed, which is the feedback loop purple teams want and rarely get from a static checklist.

How the AI agents reason

The thread running through every module is autonomous, reasoning agents rather than fixed rulesets. A classical scanner matches a pattern and emits a finding. A Pragma Core agent treats a flagged pattern as the start of an investigation: where else does this value flow, which consumer has higher privilege than the entry point, under which specific inputs is the security check actually reached, and does a confirmed request exist that proves it. That reasoning is what lets the platform confirm findings before surfacing them, which is what keeps the queue trustworthy. A finding that arrives already confirmed is a finding an engineer will fix. A finding that might be a false positive is a finding an engineer learns to ignore.

A dynamic team's operating rhythm

Put together, the platform replaces the audit-calendar rhythm with a continuous one. The table below sketches a representative day, which is really a loop that never fully stops.

Time Event
02:30 Nightly SAST and SCA sweep across all connected repos, container images rescanned
08:15 Overnight findings arrive pre-confirmed; team triages a short, high-signal queue
09:40 A merged PR triggers an on-push diff scan; one new medium finding, owner auto-assigned
13:00 Scheduled external pentest sweep re-enumerates the internet-facing surface
16:20 Operator drives an AI Security Research investigation into a fragile auth path
22:00 Weekly adversary-emulation run replays an ATT&CK playbook against detection controls

The times are illustrative, but the shape is the product: coverage is spread across the whole clock, most of it runs without a human kicking it off, and the human hours go to the deep investigations that only a person can direct.


What a dynamic AppSec team should internalize

  1. Cadence beats coverage-on-paper. A tool that runs once a year with perfect rules still leaves you blind for 360 days. Continuous, slightly-imperfect coverage catches far more real risk than a perfect annual snapshot.
  2. The dangerous bugs live between components. The flaws that cause breaches are usually about how input and state flow across functions, services, and trust boundaries, not a single obviously-bad line. Your tooling has to reason across the graph, not one node at a time.
  3. Context is what makes a finding actionable. A finding tied to its repository, branch, commit, call path, and threat model gets fixed. A finding floating in a separate dashboard gets ignored. Unification is not a convenience feature; it is the difference between signal and noise.
  4. Confirmation is the whole game for trust. A queue full of maybes trains engineers to ignore it. AI that confirms exploitability before surfacing a finding is what keeps the team acting on the queue instead of dismissing it.
  5. Depth on demand replaces the annual engagement. The ability to push an investigation deeper the moment something looks fragile, instead of waiting for the next scheduled pentest, is what turns "we scan and report" into "we systematically investigate what is fragile."

How Pragma Core fits a dynamic team's operating model

Pragma Core is built for exactly the class of team described above: one that has traded the audit calendar for a continuous, context-rich, depth-on-demand operating model. The features below are the concrete mechanics of that fit.

Native repository integration, coverage from minute one

Pragma Core connects to GitHub, GitLab, and Azure DevOps in minutes, and continuous scanning begins immediately. Findings are contextualized with repository, branch, and commit from the first scan, so a dynamic team does not spend a quarter on rollout before seeing value. The integration is the on-ramp to continuity: once the repos are connected, the coverage simply does not lapse.

Autonomous agents that investigate attack chains

The autonomous agents reason over attack chains rather than stopping at a flagged line. They ask the questions a human researcher would: where does this value flow, which consumer outranks the entry point, under which inputs is the check actually reached. For a dynamic team, this is the difference between a finding that says "user input reaches this function" and one that says "this authorization gate is skipped for a specific currency type, here is the request that proves it."

Interactive call graphs with a vulnerability overlay

Code Map auto-generates call graphs for every connected repository and overlays findings onto them, so the team sees where untrusted input propagates and precisely where it crosses a trust boundary. Because the dangerous bugs live in relationships between functions, a view of those relationships with findings drawn on top is exactly the artifact a dynamic team needs to reason about risk quickly.

SAST tuned for logic and state, not just injection sinks

Off-the-shelf static analysis is tuned for taint flows ending in SQL or shell sinks and misses logic, authorization, and state-mismatch bugs. Pragma Core's static analysis is tuned to those harder patterns: a short-circuit around a verifier, a last-write-wins state map, a type-based exemption on a security gate. For a team whose real risk lives in those patterns, that tuning is the reason the queue is worth reading.

Continuous dependency and SBOM coverage for fast response

The dependency tracker follows every third-party package across all connected repos, surfacing vulnerable versions with CVSS scores and fixed upgrade paths, including dependencies buried in containers and appliances. Paired with per-repository CycloneDX SBOMs, it answers the "which installations do we have, and which version is each" question the moment a new CVE lands, which is exactly the question that otherwise stalls an incident for days.

One workspace across code, infrastructure, and adversary emulation

The unified workspace is what makes the three domains share a brain. An exposed service from the external pentest points back at the repository that owns it; a code weakness informs the internal pentest; an ATT&CK technique that lands points at the control that failed. For a dynamic team, the workspace is the source of truth that keeps findings, ownership, and remediation in one place instead of scattered across three tool dashboards.

Human-guided investigations as a native motion

The AI Security Research module lets an AppSec operator drive a deeper investigation, supported by autonomous agents and all the context already in the workspace, focused on whatever the team feels is fragile. It is a natural extension of the subscription, not a separate black-box engagement. This is depth on demand: the same kind of investigation a specialist consultancy would run once a year, available any day the team needs it.


Closing thoughts

Pragma Core is not, fundamentally, a product about having more scanners. It is a product about changing the clock. The classical AppSec model assumes security is an event that happens on a schedule; the dynamic model assumes it is a continuous property of a system that ships every day, and it staffs and tools itself accordingly. Every feature in the platform, from continuous SAST to rolling pentests to on-demand AI research, is an expression of that single shift from cycles to continuity.

The same patterns that make a modern codebase fast to ship, many services, many dependencies, many trust boundaries crossed by ordinary requests, are exactly the patterns that hide the bugs a once-a-year audit will never see. The difference between a team that treats those patterns as a background worry and one that systematically investigates them comes down to AppSec maturity and continuous code visibility. Organizations that want to move from "we scan and report" to "we systematically investigate what is fragile," every day, can reach Pragma Core at pragma-core.com for a demo.


Sources

Related posts
CVE-2026-74820: how an unsanitized ORDER BY clause turned ServiceNow's AI Platform into an unauthenticated database backdoor
Sep 18, 2026
CVE-2026-78174: how an unredacted session token in a diagnostic log turned a low-privileged WatchGuard Dimension admin into super admin
Sep 1, 2026
Qwen 3.8 27B and the year the open weights caught up: how a 17GB download started beating the frontier
Aug 19, 2026

Start securing your codebase today

Connect your repositories and let AI agents handle continuous scanning, research, and triage.

Have questions? Get in touch →