Security is most effective when it is built into the software development lifecycle, not bolted on at the end. The goal is to make secure development a natural part of how teams work every day, enabling developers to write secure code without needing to be security experts.

Make the Secure Way the Easy (or Only) Way

One of the most effective strategies is to make the secure way the easiest — and ideally the only — way to do things. This can be achieved by:

• Providing secure libraries, tools, and defaults
• Automating security checks in the CI/CD pipeline
• Restricting use of insecure patterns or configurations via code reviews or linters

By reducing friction, teams are more likely to follow secure practices without needing constant oversight.

Secure Configuration

To prevent attacks on the software supply chain, the servers that receive executable code can be configured to enforce a more secure workflow.

Some of the settings that mitigate these risks include:

Source code repository

• Unsigned commits are rejected
• Commits by unverified users are rejected
• Users cannot push to protected branches (such as the main branch), even via force push
• Merging into protected branches must be approved
• Merge requests cannot be approved by the committer or author of the commits

CI/CD Pipeline

• Security scanning via SAST is configured in the pipeline
• Dependency scanning is configured in the pipeline
• Secret detection is configured in the pipeline
• Signing and verification of artefacts is set up

Quality Metric: Secure Configuration
Follow IM8 guidelines for configuration of workflow rules in the CI/CD pipeline and source code repository.

Using Trusted Sources

A secure foundation starts with trusted and curated sources:

• Templates and Starter Kits: Provide project scaffolds with security best practices baked in (e.g., proper headers, secure authentication flows).
• Curated Container Base Images: Use hardened, minimal images from verified sources, regularly updated for vulnerabilities.
• Controlled Software Versions: Pin dependencies to known-good versions and use tools like Dependabot or Renovate to manage updates and patches safely.

IM8 Policy: SC-4: Dependency Manifest Version Pinning
Pin direct and transitive dependency versions in the application’s dependency manifest.

These measures reduce the attack surface and ensure a consistent, auditable foundation for development.

Application Security

IM8 Policy: Application Security
Controls to prevent application vulnerabilities caused by insecure coding.

Application-layer vulnerabilities are a common target for attackers. Teams should familiarize themselves with:

• OWASP Top 10: The most common and critical web application security risks, such as injection, broken authentication, and insecure deserialization.
• OWASP ASVS (Application Security Verification Standard): A framework for defining and testing security controls in applications, useful for aligning teams on a security baseline.

Embedding checks for these risks in testing and review processes helps prevent critical vulnerabilities from reaching production.

Threat Modelling

Threat Modelling is a proactive technique to identify and mitigate potential security issues before implementation. One popular framework is STRIDE, which helps teams consider six categories of threats:

• Spoofing identity
• Tampering with data
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege

Threat modelling can be done during design sessions and revisited during major changes to architecture or functionality.

Security User Stories

To embed security into agile development, teams can use Security User Stories, which make security requirements visible and actionable. These often include:

• Security Acceptance Criteria: Clear definitions of what “secure” means for a feature, e.g., “passwords must be stored using bcrypt.”
• Security Personas: Represent malicious actors (e.g., “Malicious Insider,” “External Attacker”) to help teams think from an attacker’s perspective.
• Security Tests: Automated or manual tests that validate the feature against its security requirements.

By including security in user stories, teams ensure it’s considered as early as possible in the process.

Secure Code Review

Secure Code Review is a critical quality assurance step that helps identify vulnerabilities and insecure coding practices before code is merged or released. This can be done manually by trained developers or augmented with static analysis tools. The focus is on spotting issues such as improper input validation, insecure data handling, or misuse of authentication and authorization mechanisms. Making secure code review a standard part of the pull request process not only improves code quality but also increases team awareness of secure development practices over time.

Summary

Building security in means treating it as a first-class concern, not an afterthought. By using trusted sources, embedding application security practices, performing threat modelling, and integrating security into user stories and acceptance criteria, teams can proactively reduce risk and create resilient, secure software from the start.