Modern software delivery is no longer just code → build → deploy. It’s code → decisions → risk → runtime outcomes. The hard part isn’t a lack of data—it’s that SDLC data is fragmented across tools, and the meaning of a change is scattered across approvals, exceptions, scan results, rollout strategy, and incident timelines.
OpsMx builds an SDLC Context Graph to solve this: a continuously updated, permission-aware graph that links the entire code-to-cloud lifecycle so teams (and AI agents) can reliably answer:
- What changed?
- Where is it running?
- What risk did it introduce?
- Why was it allowed?
- What should we do next—and can we do it safely?
This blog explains how OpsMx constructs an SDLC context graph through its platform.
What is an SDLC Context Graph?
An SDLC context graph is a living model of the software lifecycle that combines:
- Entities (repos, services, PRs, builds, images, clusters, policies, findings, incidents, owners)
- Relationships (“produced by,” “deployed to,” “depends on,” “owned by,” “violates,” “mitigated by,” “approved by”)
- Traces over time (the timeline of actions and decisions: gates, exceptions, approvals, rollouts, incident correlation, remediation)
This third layer—decision and action traces—is what separates a context graph from a static inventory or reporting pipeline. It answers “why” and enables safe automation.
Why OpsMx Builds an SDLC Context Graph
An SDLC context graph helps solve three persistent problems:
1) Risk is contextual, not a standalone finding
A CVE’s severity is not the same as enterprise risk. Risk depends on whether it’s deployed, exposed, in production, tied to regulated data, or mitigated by compensating controls.
2) Incidents require fast change correlation
When systems break, teams need an immediate answer to: “What changed?”—including deploys, config changes, feature flags, dependency upgrades, and policy exceptions.
3) Automation needs governance and auditability
Auto-remediation only works if actions are authorized, scoped, explainable, and recorded as evidence. A context graph becomes the foundation for contextual trust.
How OpsMx Constructs the SDLC Context Graph
OpsMx constructs the SDLC context graph in five layers.
1) SDLC Connectors: ingesting code-to-cloud signals from existing tools
OpsMx integrates with systems that define software delivery and operational reality:
- Source control: PRs, commits, reviews, branches, tags
- CI/CD and release: pipeline runs, tests, artifacts, releases
- Supply chain: registries, SBOMs, signatures, attestations
- Runtime: Kubernetes, cloud inventory, deployments, rollouts
- Security and posture: SAST/SCA/DAST, CSPM/CNAPP, secrets scanning, policy engines
- Operations: incidents, alerts, runbooks, tickets, on-call
Each connector produces:
- Events (PR merged, build completed, deploy applied)
- Snapshots (inventory, current deployments, current policies)
2) Normalization: canonical SDLC event and trace model
Every tool speaks a different language. OpsMx normalizes tool-specific data into a consistent SDLC trace model so downstream reasoning is stable.
Example canonical traces:
- CodeChangeTrace: PR opened → reviewed → merged
- BuildTrace: build started → tests executed → artifact produced
- SupplyChainTrace: SBOM generated → image signed → attestation created
- DeployTrace: deployment initiated → rollout strategy → target env → result
- PolicyTrace: policy evaluated → outcome → violated controls → exception applied
- IncidentTrace: alert fired → incident opened → mitigated → resolved
- RemediationTrace: recommendation → PR raised → executed → verified
This avoids the “data lake trap.” The goal is not to store everything; it’s to produce structured traces that are explainable and queryable.
3) Ontology mapping: SDLC entities and relationships
OpsMx maps normalized traces into an SDLC ontology (a consistent vocabulary of entities and edges).
Code & ownership
- Repo, Branch, Commit, PR, Developer, Reviewer, Team, Service
Pipeline & supply chain
- Build, Test, Scan, Gate, Release, Artifact, Image, SBOM, Attestation
Runtime
- Environment, Cluster, Namespace, Deployment, Workload, Config, Feature Flag
Risk & governance
- Policy, Control, Finding, Vulnerability, Misconfiguration, Exception, CompensatingControl
Operations
- Alert, Incident, Runbook, ChangeWindow, reliability signals
Common relationships:
- PR → merged_into → main
- Build → produces → Artifact/Image
- Image → deployed_to → Deployment
- Deployment → runs_in → Namespace/Cluster
- Service → owned_by → Team
- Finding → affects → Image/Service
- Policy → evaluated_on → PR/Build/Deploy
- Exception → approved_for → Finding/Control
- Incident → correlates_with → DeployTrace/ConfigChange
4) Identity resolution and linkage: accurate lineage and correlation
The hardest part of SDLC graphs is linking records across systems:
- Which commit belongs to which PR?
- Which build produced which image digest?
- Which image digest is running in production?
- Who owns a deployment in a shared cluster?
- Which incident correlates to which change?
OpsMx improves accuracy using:
- Stable identifiers (commit SHA, image digest, artifact checksum, deployment UID)
- Metadata fingerprints (labels, annotations, provenance)
- Time-window correlation (change at T correlates with incident at T+Δ)
- Service ownership mapping (service catalog, on-call mapping, team rules)
- Graph constraints (preventing impossible joins; enforcing expected lineage)
Where correlation is probabilistic, the graph can record confidence—critical for safe automation.
5) Contextual trust: securing access for humans and third-party agents
An SDLC context graph is sensitive (architecture, vulnerabilities, deployment targets, incidents). OpsMx secures it with:
- Fine-grained access control (team and environment boundaries)
- Redaction policies (sensitive fields, restricted evidence)
- Audit trails (who queried what, when, and why)
- Contextual authorization (actions allowed only under specific conditions)
This makes the context graph usable by third-party agents (incident, security, or coding agents) without overexposing data—and ensures actions are controlled and traceable.
What the OpsMx SDLC Context Graph Enables
Risk assessment in context (security + compliance + operational)
- Which vulnerabilities are deployed in production right now?
- Which findings affect crown-jewel services or regulated data paths?
- Which policy exceptions are expiring, and what compensating controls exist?
- Which services show the highest risk-adjusted change failure rate?
Operational diagnosis and incident response
- What changed in the last N minutes for the impacted service?
- Was the incident correlated with a deploy, config change, or feature flag?
- What is the dependency blast radius?
Automated remediation with guardrails
- Generate safe PR-based fixes (patch, pin, config update)
- Apply compensating controls with explicit expiry
- Execute runbook steps with approval gates
- Verify outcomes and close the evidence loop automatically
Example: A “Change Story” Built from the Graph
A change story derived from the SDLC context graph might include:
- PR #842 merged by Alice, reviewed by Bob
- Build #551 produced image digest D
- SBOM attached; image signed with attestation
- Deployed to payments-prod via canary rollout (10% → 50%)
- Policy check found 1 critical CVE → exception approved until date X with compensating control Y
- 20 minutes later: incident opened on error-rate spike
- Correlation suggests dependency upgrade in the PR
- Recommendation: rollback timeout config; open PR to pin dependency version
That’s a replayable, auditable narrative—not a dashboard.
Minimum Viable SDLC Context Graph (Fast Start)
To deliver results quickly, OpsMx typically starts with:
Connectors
- Git + CI/CD
- Registry + Kubernetes runtime
- One risk source (SCA/CSPM) + one incident source (PagerDuty/Jira)
Core relationships
- PR/commit → build → image → deploy → runtime
- finding → affected asset → environment → owner
- incident → correlated change → recommended remediation
OpsMx Enterprise Delegate: simplify discovery, ingestion, security, and data residency
To make this fast-start practical in large enterprises, OpsMx provides an Enterprise Delegate that runs close to your systems. It is designed to simplify:
- Discovery: quickly identify the right repos, clusters, accounts, and projects to onboard
- Ingestion: securely pull events and snapshots from SDLC and runtime tools with minimal friction
- Security: enforce least-privilege access, token scoping, and connector isolation
- Data residency: keep sensitive data in-region or in-environment by controlling what leaves your boundary
In practice, the Enterprise Delegate helps teams onboard new sources faster while maintaining enterprise-grade governance.
From there, expand into deeper supply chain (SBOM/attestations), compliance evidence mapping, IAM/privilege relationships, and more operational signals.
Frequently Asked Questions
What’s the difference between a knowledge graph and an SDLC context graph?
A knowledge graph models entities and relationships. An SDLC context graph adds time-indexed traces and decision history (gates, approvals, exceptions, rollouts, outcomes) so you can explain “why” and automate safely.
Do we need to ingest all tools to get value?
No. Value comes from a minimal set that covers change lineage, runtime truth, and risk/incident signals. Start with 3–5 systems, then expand.
How does this support AI agents safely?
Agents can query the graph for accurate context and propose actions. Execution is governed by contextual trust: least privilege, policies, approvals, and audit trails.
0 Comments