Technology Shield — Secure Development Framework
A comprehensive framework for embedding security into the software development lifecycle, built on battle-tested CI/CD template patterns.
Version: 0.1.0 Status: Draft Author: Technology Shield Last Updated: 2026-03-25
1. What Is the Secure Development Framework?
The Secure Development Framework (SDF) is Technology Shield's approach to making software development secure by default, not secure by afterthought.
It draws on the real-world work of the CI-Template — a set of reusable, composable CI/CD pipeline components that embed security toolchains directly into the development workflow. Instead of bolting security on at the end, the SDF ensures that every commit, build, test, and deployment passes through a security-aware pipeline.
The result: development teams ship faster with confidence, and security teams get assurance without being a bottleneck.
2. The Problem
| Problem | Impact |
|---|---|
| Security is a gate at the end | Late findings are expensive to fix and delay releases |
| Security tooling is disconnected from dev workflow | Developers ignore results they never see |
| Every team builds their own pipeline | Inconsistent security coverage across projects |
| Security scanning results are noisy | Teams drown in false positives and stop looking |
| No baseline for "good enough" | Every project negotiates its own standard |
| Compliance evidence is manual | Auditors ask for evidence that doesn't exist in a usable form |
3. Framework Architecture
The SDF operates across five layers:
┌─────────────────────────────────────────────────────────┐
│ GOVERNANCE LAYER │
│ Policy definitions, quality gates, compliance mappings │
├─────────────────────────────────────────────────────────┤
│ PIPELINE LAYER │
│ CI-Template: composable, reusable pipeline components │
├────────────┬────────────┬────────────┬──────────────────┤
│ BUILD │ TEST │ DEPLOY │ RELEASE │
│ Security │ Security │ Security │ Security │
│ Checks │ Checks │ Checks │ Checks │
├────────────┴────────────┴────────────┴──────────────────┤
│ TOOLCHAIN LAYER │
│ SAST, SCA, DAST, Secret Scanning, IaC Scanning, │
│ Container Scanning, License Compliance, SBOM │
├─────────────────────────────────────────────────────────┤
│ REPORTING LAYER │
│ Dashboards, trend analysis, compliance evidence, │
│ integration with Shield Business │
└─────────────────────────────────────────────────────────┘
4. The CI-Template
The CI-Template is the engine of the SDF. It provides reusable, composable pipeline components that teams include in their CI/CD configuration.
4.1 Design Principles
| Principle | Description |
|---|---|
| Composable | Teams assemble the pipeline stages they need from a library of components |
| Opinionated defaults | Every component ships with sensible, secure defaults |
| Overridable | Teams can adjust thresholds and configuration, within governance-defined boundaries |
| Language-aware | Components detect the project language and apply appropriate tooling |
| Fail-safe | Security failures break the build by default; exceptions must be explicit |
| Auditable | Every pipeline run produces structured evidence of what was checked and what was found |
4.2 Pipeline Stages
Pre-Commit
| Check | Purpose | Tooling Examples |
|---|---|---|
| Secret scanning | Prevent credentials from entering the repository | gitleaks, truffleHog |
| Commit signing | Verify author identity | GPG, SSH signing |
| Pre-commit hooks | Lint, format, basic security checks before code leaves the developer machine | pre-commit framework |
Build
| Check | Purpose | Tooling Examples |
|---|---|---|
| SAST (Static Analysis) | Identify code-level vulnerabilities | Semgrep, CodeQL, SonarQube |
| SCA (Software Composition Analysis) | Identify vulnerable dependencies | Snyk, Trivy, Dependabot |
| License compliance | Ensure dependency licenses are compatible | FOSSA, licensee |
| SBOM generation | Produce a software bill of materials | Syft, CycloneDX |
| IaC scanning | Identify misconfigurations in infrastructure code | Checkov, tfsec, KICS |
Test
| Check | Purpose | Tooling Examples |
|---|---|---|
| Unit test security assertions | Validate security-relevant behaviour | Language-native test frameworks |
| Integration test security scenarios | Test authentication, authorisation, input validation flows | Custom test suites |
| DAST (Dynamic Analysis) | Test running application for vulnerabilities | OWASP ZAP, Nuclei |
| API security testing | Validate API contracts and security headers | Dredd, Postman + security collections |
Deploy
| Check | Purpose | Tooling Examples |
|---|---|---|
| Container image scanning | Identify vulnerabilities in container images | Trivy, Grype, Snyk Container |
| Image signing and verification | Ensure only trusted images deploy | Cosign, Notary |
| Policy-as-code validation | Enforce deployment policies | OPA/Gatekeeper, Kyverno |
| Environment configuration validation | Verify target environment matches security baseline | Cloud Blueprint integration |
Release
| Check | Purpose | Tooling Examples |
|---|---|---|
| SBOM publication | Publish bill of materials for the release | CycloneDX, SPDX |
| Vulnerability disclosure | Generate advisory if known vulnerabilities accepted | VEX |
| Compliance evidence package | Bundle all security evidence for the release | SDF reporting layer |
| Release signing | Cryptographically sign the release artefact | Sigstore, GPG |
4.3 Quality Gates
Quality gates are the decision points in the pipeline. Each gate has:
| Component | Description |
|---|---|
| Gate ID | Unique identifier (e.g. GATE-BUILD-001) |
| Stage | Which pipeline stage this gate belongs to |
| Condition | What must be true to pass (e.g. "zero critical SAST findings") |
| Threshold | Configurable severity/count thresholds |
| Action on Fail | Block / Warn / Record |
| Exception Process | How to request a waiver and for how long |
| Evidence | What is recorded when the gate is evaluated |
Default gate policy:
| Severity | Default Action |
|---|---|
| Critical | Block deployment |
| High | Block deployment |
| Medium | Warn; require acknowledgement |
| Low | Record; visible in dashboard |
| Informational | Record only |
5. Governance Integration
The SDF connects into the broader Technology Shield governance model:
| Integration Point | How |
|---|---|
| Pattern Blueprint | Pipeline components validate that implementations conform to approved patterns |
| Cloud Blueprints | IaC scanning validates against Cloud Blueprint hardened baselines |
| Security Reference Architecture | Deployment policies enforce zoning model compliance |
| Shield Business | Pipeline findings feed into Shield Business for risk reporting |
| Risk Register | Accepted vulnerabilities create risk register entries |
6. Adoption Model
Tier 1 — Quick Start
For teams that need immediate security coverage:
- Include the CI-Template base configuration in your pipeline
- Automatic language detection enables default tooling
- Default quality gates apply
- Results visible in pipeline output and basic dashboard
Time to value: Hours.
Tier 2 — Customised
For teams with specific requirements:
- Select and configure individual pipeline components
- Adjust quality gate thresholds to your risk appetite
- Integrate with your existing security tooling
- Configure reporting and alerting
Time to value: Days.
Tier 3 — Governed
For organisations that need enterprise-grade governance:
- Define organisation-wide gate policies
- Enforce minimum security stages across all projects
- Centralise reporting in Shield Business
- Map findings to compliance frameworks
- Automate evidence collection for audits
Time to value: Weeks.
7. Supported Platforms
The CI-Template is designed to work across major CI/CD platforms:
| Platform | Support Level |
|---|---|
| GitLab CI | First-class (CI-Template native format) |
| GitHub Actions | Supported via reusable workflows |
| Azure DevOps | Supported via pipeline templates |
| Jenkins | Supported via shared library |
| Bitbucket Pipelines | Community-contributed |
8. What Makes This Different
| Aspect | SDF Approach | Typical "Shift Left" |
|---|---|---|
| Starting point | Reusable templates, not blank pipelines | Every team starts from scratch |
| Defaults | Secure by default; opt out requires justification | Insecure by default; security is opt-in |
| Governance | Organisational policy enforced through pipeline | Policy exists in documents, not in automation |
| Evidence | Structured, machine-readable, auditable | Screenshots and manual reports |
| Developer experience | Security is part of the workflow, not a separate tool | Developers must context-switch to security tools |
| Feedback loop | Findings in the PR/MR, not in a separate portal | Security findings arrive weeks later |
9. Roadmap
| Phase | Focus |
|---|---|
| Current | Core CI-Template components for SAST, SCA, secret scanning, container scanning, IaC scanning. GitLab CI and GitHub Actions. Basic quality gates. |
| Next | DAST integration, SBOM lifecycle, policy-as-code for deployment, Shield Business integration, compliance evidence automation. |
| Future | AI-assisted triage (reducing false positives), cross-project vulnerability correlation, supply chain attestation, Secure Collaborative Development Architecture integration. |
10. Getting Started
For Technology Shield consulting clients: The SDF is deployed as part of DevOps Security engagements. We configure the CI-Template for your environment, set up quality gates aligned to your risk appetite, and train your teams.
For self-service adoption: The CI-Template core components are available as open-source. Organisation-wide governance features and Shield Business integration are available through Technology Shield subscriptions.
Contact: Reach out via the Technology Shield website to discuss your development security posture.