DevSPM: Unifying Vulnerability Detection and Creation-Origin Context in Software Security
Earlier research, published before Salmon. It reflects Archipelo's work on developer security posture management at the time of writing and does not describe Execution Verification Infrastructure.

Application security platforms detect vulnerabilities in software artifacts. But when teams investigate risk, they must also understand how those artifacts were created. Connecting detection with development-origin context provides that missing perspective.
Modern application security workflows operate across two distinct surfaces:
1. Artifact detection — identifying vulnerabilities in code, dependencies, configuration, and build outputs.2. Creation-origin context — understanding how and under what conditions those artifacts were introduced.
Most security platforms specialize in the first surface.
Investigation and remediation frequently require the second.
As software creation increasingly incorporates AI-assisted workflows alongside human development, the boundary between detection and origin becomes operationally significant.
Detection and Its Boundary
Application security platforms evaluate artifacts:
- Source code
- Dependencies
- Configuration
- Build outputs
These systems determine:
- Whether a vulnerability is present
- Its severity
- Its potential exposure
Detection establishes that risk exists.
It does not inherently record the conditions under which the change was introduced.
When a finding is surfaced, investigation typically requires reconstruction across:
- Version control history
- Pull request metadata
- Pipeline events
- Contributor activity
This reconstruction process becomes more complex in hybrid human and AI-assisted development environments.
Creation Conditions and Attribution
A single code change may involve:
- A human identity
- AI-generated logic
- Workflow automation
- Tool-invoked modifications
Commit metadata does not always distinguish between these contributing elements.
During remediation, organizations often need to determine:
- Which identity initiated the change
- Whether AI tooling participated
- Which workflow conditions were present at creation
These are questions about origin, not artifact state.
Developer Security Posture Management (DevSPM)
Developer Security Posture Management (DevSPM) focuses on observable developer actions during software creation.
It associates code changes with the developers and AI-assisted workflows that produced them across source control and CI/CD systems.
When correlated with vulnerability findings, this produces development-origin context — attributable information identifying the identity and actions involved in how risk entered the codebase.
DevSPM does not replace artifact-focused security systems.
It introduces additional context at the creation layer that can be incorporated into existing investigation and governance workflows.
The Partnership with Checkmarx
Archipelo and Checkmarx have partnered to correlate vulnerability findings with development-origin context within software delivery workflows.
Checkmarx provides application security testing and Application Security Posture Management (ASPM) to identify and manage software risk across development pipelines.
Archipelo provides creation-layer visibility through DevSPM.
Together, these systems allow organizations to analyze:
1. The presence of risk2. The recorded conditions under which it was introduced
This alignment connects artifact detection with attributable origin context inside existing security workflows.
Practical Illustration
Consider a vulnerability detected in a repository.
Traditional workflow:
- The issue is identified.
- Teams review commit history.
- Investigation relies on manual correlation of events.
With correlated origin context:
- The associated developer identity is known.
- AI-assisted workflow participation is observable.
- Workflow metadata at creation is recorded.
- Investigation incorporates recorded signals alongside detection results.
The difference lies in the availability of attributable creation evidence during remediation.
Why Creation Context Matters
As development workflows incorporate AI-assisted tooling and automation, software creation becomes distributed across identities and systems.
Security analysis that relies solely on artifact inspection may not capture the conditions under which a change was introduced.
Incorporating creation-layer context allows investigation processes to reference recorded identity and action data in addition to artifact state.
Detection and origin serve distinct roles within the same workflow.
Closing Observation
Detection determines that a vulnerability exists.
Origin context identifies the conditions under which it was introduced.
Application security workflows incorporate both perspectives when investigation requires attributable evidence.