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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- SAST Scanning. AI-powered static analysis that is tuned to find the vulnerabilities other tools miss: not just the taint flows ending in an obvious SQL or shell sink, but logic, authorization, and state-mismatch bugs that live in how functions relate to each other.
- DAST. AI-driven dynamic testing of live applications that returns confirmed findings, so a reported issue comes with evidence of exploitability rather than a maybe.
- SCA / Dependency Tracker. Continuous tracking of third-party packages across every connected repository, with CVE data and concrete fixed-version upgrade paths, including dependencies buried inside containers and appliances.
- SBOM Generation. A full component inventory per repository, exportable as CycloneDX JSON for compliance and for fast incident response.
- Code Map. Interactive call graphs that visualize how classes, functions, and calls connect, with findings overlaid so you can see exactly where untrusted input propagates and where it crosses a trust boundary.
- Threat Model. An auto-built STRIDE data-flow diagram of your architecture, AI-enriched, that updates with the code instead of rotting in a diagramming tool.
- AI Security Research. Autonomous agents that investigate complex vulnerabilities in depth, following an attack chain across the codebase the way a human researcher would.
- Code Quality Checks. Detection of dead code, complexity hotspots, and anti-patterns, because the messiest code is where the security bugs hide.
- CI/CD Pipeline Security. Daily scans across five CI platforms, so the build and delivery path itself is treated as attack surface, not trusted infrastructure.
- Container Image Scanning. CVE identification in base images, closing the gap between "our code is clean" and "the image we ship it in is not."
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.
- Infrastructure Penetration Tests. An agentic internal pentest with full Active Directory and BloodHound coverage, which maps privilege-escalation and lateral-movement paths the way an internal attacker would after a foothold.
- External Penetration Testing. An AI-run external pentest across CIDRs, IP ranges, ASNs, and domains, which continuously enumerates and probes the internet-facing surface instead of snapshotting it once a year.
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
- 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.
- 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.
- 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.
- 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.
- 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
- Pragma Core, Product overview and platform capabilities, pragma-core.com, accessed July 2026.
- Pragma Core, Application Security module descriptions (SAST, DAST, SCA, SBOM, Code Map, Threat Model, AI Security Research), pragma-core.com.
- Pragma Core, Infrastructure Security and Adversary Emulation module descriptions, pragma-core.com.
- MITRE ATT&CK, Enterprise matrix, attack.mitre.org.