DevSecOps shift-left
Security defects cost least when they are found during design and most when they are found in production. Shift-left means moving the security work to where the cost is lowest — and giving the customer the understanding to keep it there.
The standard. Customers understand the security model of their environment, and security activities are embedded in every phase of delivery rather than reviewed at the end.
What the customer needs to understand
Shared responsibility
The boundary between what AWS secures and what the customer secures moves with the service. A customer who does not understand it will assume a control exists that does not.
| Service | AWS secures | Customer secures |
|---|---|---|
| EC2 | Hypervisor, hardware, network | OS patching, application, IAM, network config |
| RDS | Database engine patching, backups infrastructure | Data, access control, encryption choice, network |
| Lambda | Runtime, scaling, OS | Function code, IAM role, dependencies, configuration |
| S3 | Durability, storage infrastructure | Bucket policy, encryption, access, object content |
AWS security fundamentals
An onboarding session covers:
- The shared responsibility model, with the customer's actual services.
- Identity and access: IAM roles, policies, Identity Center, MFA, least privilege.
- Network security: VPC, subnets, security groups, NACLs, endpoints, flow logs.
- Data protection: encryption at rest and in transit, KMS, Secrets Manager.
- Detection: CloudTrail, Config, GuardDuty, Security Hub.
- Logging and evidence: what is recorded, where it is kept, how it is used.
Qbits security practices
The customer receives the standards in this library — particularly Security best practices and Security use cases — so they can see the controls applied to their environment and reproduce them.
IAM best practices
| Practice | Reason |
|---|---|
| Least privilege | Limits the blast radius of a compromised identity |
| Roles over access keys | Removes long-lived credentials |
| MFA for console access | Blocks credential-only compromise |
| Rotate credentials | Limits the value of a leaked credential |
| Monitor with CloudTrail and Access Analyzer | Detects misuse and over-permission |
| Groups for permission management | Makes access review tractable |
| Strong password policy | Removes the easiest attack |
| No root for daily work | Root is the highest-value target |
| Organisations for policy | Applies controls consistently across accounts |
No * in custom policies | Forces explicit thinking about permission |
Security in each phase
Plan → threat model, security requirements, data classification
Design → architecture review, least-privilege design, encryption plan
Code → secure coding standards, peer review, pre-commit secret scan
Build → SAST, dependency scan, image scan, SBOM
Test → DAST, penetration testing, misconfiguration scan
Release → policy gate, signed artefact, approval
Deploy → immutable infrastructure, least-privilege deployment role
Operate → detection, patching, access review, incident response
| Phase | Activity | Tool |
|---|---|---|
| Plan | Threat model; define security acceptance criteria | Workshop; STRIDE or attack-tree |
| Design | Architecture review for least privilege, segmentation and encryption | Review record |
| Code | Secure coding standards; secret scanning; peer review | Pre-commit hooks, gitleaks |
| Build | SAST; dependency scan; container image scan; SBOM | SonarQube, Snyk/Trivy, syft |
| Test | DAST against a running environment | OWASP ZAP |
| Release | Policy evaluation; approval | Config, CloudFormation Guard |
| Deploy | OIDC roles; immutable artefact; change approval | GitHub Actions environments |
| Operate | Patch compliance, access review, detection tuning | Systems Manager, GuardDuty, Security Hub |
Secure CI/CD pipeline
A pipeline is secure when:
- Every stage has a security gate, not just one at the end.
- The gates block. A scan that reports but does not fail is a report.
- The pipeline's own credentials are short-lived. OIDC, scoped to repository and branch.
- The artefact is traceable. SBOM and provenance attached.
- The deployment role is least-privilege. It can deploy, not administer.
- Production requires approval. Recorded, with a named approver.
Gate sequence
commit
├─ secret scan → block on any finding
├─ SAST → block on new critical/high
├─ dependency scan → block on critical with a fix
├─ build
├─ image scan → block on critical
├─ SBOM + provenance
└─ policy check → block on violation
What "shift-left" does not mean
- It does not mean removing pre-release testing. DAST and penetration testing still happen; they just stop being the only security activity.
- It does not mean blocking every commit on every scanner. Gates are tuned to findings that matter; an unusable pipeline gets bypassed.
- It does not mean developers own security alone. It means security expertise is available during design, not only at review.
Education programme
| Format | Audience | Content |
|---|---|---|
| Onboarding session | Customer engineering and operations | Shared responsibility, IAM, network, data protection, detection |
| Secure coding workshop | Developers | Input validation, secrets, dependency management, error handling |
| Pipeline walkthrough | Developers and DevOps | Gates, how to read a failure, how to fix rather than suppress |
| Incident exercise | Operations and security | Detection through to recovery, using the customer's runbooks |
| Quarterly security review | Leadership and security | Posture trend, open risks, decisions |
Education is recorded and the materials are handed over, so the customer can run the sessions for new joiners.
Evidence
- Onboarding deck and materials.
- Secure SDLC process description with the gates per phase.
- Pipeline configuration showing the security stages.
- Sample scan reports and their resolution.
- Training attendance records.
- The customer's own security runbook set.