Shared Responsibility Model
ExplanationPublic
The problem this solves
Compliance responsibility in a DevSecOps platform is never entirely owned by the vendor or entirely by the operator. Misunderstanding the line leads to gaps in ATO packages and surprises during audits.
The three responsibility zones
SmoothGlue owns
- Platform infrastructure security (FIPS, DISA STIG, Kyverno zero-trust network policies)
- Pre-integrated tool hardening (GitLab, Keycloak, ArgoCD, Nexus — all ship with hardened defaults)
- SBOM generation and pipeline gating for images built through Pillars of Creation
- Platform Custodian continuous compliance enforcement and evidence generation
- Iron Bank image provenance — base images come from DoD-hardened Iron Bank registry
Your team (operator) owns
- Application code and its security posture
- Application-level secrets (stored in Vault, managed by your team)
- RBAC configuration in the Console (who has what role)
- Data handled by applications running on the platform
- ATO package assembly and risk acceptance sign-off
Your agency owns
- Acceptance of residual risk after reviewing the split above
- Agency-specific policy overlays beyond the SmoothGlue baseline
- User account lifecycle for personnel (SmoothGlue provides the SSO mechanism; your agency manages who gets accounts)
The ATO conversation
When your ISSO asks "what does this platform cover?" — everything above the application layer. Infrastructure, pipeline, runtime security enforcement, and compliance evidence generation are SmoothGlue's responsibility. Your application's behavior and data handling are yours.