Most software vulnerabilities are not the result of sophisticated zero-day attacks. They arise from preventable gaps in development practice: weak authentication, unencrypted data, untested code paths, and misconfigured cloud environments. The cost of addressing these gaps after a breach is consistently higher than building security into the development process from the start.
This seven-step checklist covers the security measures that prevent the most common attack vectors in software development. Use it as a planning tool when starting a new project, or as an audit against your existing practice. For the underlying principles, see our guide to protecting software development from cyberattacks.
Step 1: Adopt a Secure Software Development Lifecycle (Secure SDLC)
Security vulnerabilities are significantly cheaper to address during development than after deployment. A Secure SDLC embeds security at every phase of the build rather than treating it as a final gate, which is why most regulated-sector and enterprise engineering teams now require it as a development standard.
- Integrate security into all development phases from planning through deployment, not only testing
- Conduct threat modelling and risk assessments at the architecture stage before writing code
- Require developer training in secure coding to prevent common vulnerabilities at their source
- Implement secure coding guidelines following the OWASP Top 10 as a minimum baseline
Security issues found in code review cost a fraction of those found after deployment. The Secure SDLC is where most of the cost savings in security come from.
Step 2: Enforce Strong Authentication and Access Control
Brute-force attacks, credential stuffing, and privilege escalation are among the most common and most preventable attack vectors. They all exploit the same gap: insufficient controls on who can access what. Limiting access to the minimum genuinely required is the most effective single reduction in attack surface available to most teams.
- Require multi-factor authentication (MFA) for all users, developers, and service accounts with access to production systems
- Apply the principle of least privilege: every user and service should have only the minimum access required to do its job
- Use role-based access control (RBAC) to restrict who can modify code, infrastructure, and sensitive configuration
- Encrypt sensitive credentials and enforce secure API key storage with rotation policies
Teams that apply least privilege consistently contain breaches that would otherwise spread across entire systems. The blast radius of a compromised credential is determined by access control decisions made before the incident, not during it.
Step 3: Implement Secure Coding Practices
SQL injection, cross-site scripting (XSS), buffer overflows, and remote code execution are among the most consistently exploited vulnerability types in web applications, and all trace back to insecure coding patterns. Static and dynamic analysis tools catch these patterns before they reach production, which is why they belong in the CI/CD pipeline rather than in a pre-release security audit. Our overview of secure coding strategies for software developers covers the patterns in depth.
- Conduct regular static and dynamic code analysis in the CI/CD pipeline to detect vulnerabilities continuously
- Use parameterised queries for all database interactions to prevent SQL injection
- Sanitise and validate all user inputs to prevent cross-site scripting and injection attacks
- Require peer code reviews with an explicit security focus, not just functional correctness
Secure coding is where you prevent problems from being introduced in the first place. The other steps in this checklist catch what slips through, but none of them substitute for code that is written to be secure.
Step 4: Protect APIs and Data Through Encryption
APIs are high-value attack targets because they expose business logic and user data to external systems. An unprotected endpoint can allow data extraction, transaction manipulation, or service disruption. Unencrypted data in transit or at rest carries the same exposure at the network and storage layers.
- Use HTTPS and TLS for all data transmissions: any unencrypted endpoint is an exploitable one
- Encrypt stored data using AES-256 to prevent unauthorised access to databases and file stores
- Implement OAuth 2.0 for secure API authentication and authorisation across all integrations
- Audit API endpoints regularly to identify exposure, including unused and legacy endpoints that teams have forgotten remain externally accessible
The combination of TLS in transit and AES-256 at rest addresses the majority of data exposure risks. API auditing closes the gap between what teams believe is exposed and what is actually accessible externally.
Step 5: Perform Security Testing and Penetration Testing
No development process eliminates all vulnerabilities. Security testing finds what the other controls missed: misconfigured permissions, logic flaws in authentication flows, and dependency vulnerabilities that were not present when the code was written but have since been disclosed.
- Schedule penetration testing at minimum quarterly and after significant architectural changes or major feature releases
- Automate security scanning in CI/CD pipelines using tools like OWASP ZAP or Snyk to catch regressions continuously
- Simulate DDoS conditions to validate system resilience under abnormal load profiles
- Conduct fuzz testing to expose hidden security flaws in input handling across API and form surfaces
Continuous scanning in the pipeline catches regressions at the point they are introduced. Quarterly penetration testing by qualified external testers catches the deeper issues automated tools miss. Both are necessary.
Step 6: Secure Cloud Environments and Third-Party Dependencies
Cloud misconfiguration and compromised third-party libraries are two of the most common sources of successful attacks against modern applications. Misconfigured storage buckets, overly permissive IAM policies, and unaudited npm or PyPI packages have each caused significant incidents at organisations with otherwise mature security practices.
- Apply zero-trust security principles: verify every access request regardless of its origin, including internal service-to-service calls
- Audit third-party libraries for known CVEs before integrating them, and monitor them continuously with tools like Dependabot
- Apply container security best practices for Kubernetes and Docker environments, including image scanning and least-privilege service accounts
- Review cloud configurations against security benchmarks to prevent accidental exposure through misconfigured storage, IAM policies, or network rules
Supply chain attacks via compromised third-party packages have become a meaningful attack vector, with packages published to npm, PyPI, and similar registries used as delivery mechanisms. Dependency auditing is no longer an optional practice for teams building on open-source foundations.
Step 7: Establish an Incident Response Plan
No system is completely immune to attack. A well-documented incident response plan determines whether a breach is contained quickly, or escalates into an extended incident with regulatory, financial, and reputational consequences. The NIST Computer Security Incident Handling Guide (SP 800-61) provides the standard four-phase structure: preparation, detection, containment, and recovery.
- Document the incident response plan with clear roles, responsibilities, and escalation paths before an incident occurs, not during one
- Set up automated alerting for real-time threat detection across systems, APIs, and access logs
- Train all team members on phishing awareness and security protocols: human error remains the most consistent attack entry point
- Conduct regular breach response drills to test whether the plan works under pressure, not just on paper
Teams that have run drills respond faster, contain damage more effectively, and communicate more clearly with stakeholders when an actual breach occurs. The difference between a contained incident and a catastrophic one is almost always preparation made before the event.
Security as a Development Practice
These seven steps address the attack vectors that cause most software security incidents: weak authentication, insecure code, unprotected APIs, inadequate testing, misconfigured environments, and unplanned incident response. Each is individually preventable. Together, they form a systematic approach to security that reduces risk at every layer of the development stack.
The most important shift is treating security as a development practice rather than a deployment gate. Security issues found in code review cost a fraction of those found after deployment, and a fraction of those found after a breach. To discuss how security-first development works in practice, speak to Scrums.com.
Frequently Asked Questions
What is a Secure Software Development Lifecycle (Secure SDLC)?
A Secure SDLC is a development approach that integrates security activities at every stage of the build rather than treating security as a final review before deployment. It includes threat modelling at the architecture stage, secure coding requirements during development, automated security scanning in CI/CD pipelines, and penetration testing before major releases. Security issues are found and fixed earlier, when they are cheapest to address.
Why are APIs a common target for cyberattacks?
APIs expose business logic and user data to external systems, making them accessible to anyone who can discover and call the endpoints. Poorly secured APIs can allow data extraction in bulk, transaction manipulation, authentication bypass, or service disruption. The risk is compounded by legacy endpoints that teams have forgotten exist but remain externally accessible. OAuth 2.0 authentication, TLS encryption, and regular endpoint audits are the baseline protections.
How often should software teams conduct penetration testing?
At minimum quarterly and after any significant architectural change, new feature release, or infrastructure change. Many organisations in regulated industries conduct penetration testing more frequently or use continuous automated scanning in the CI/CD pipeline. Penetration testing should be performed by qualified security professionals external to the team that built the system, to ensure genuinely independent assessment rather than internal validation.
What is the zero-trust security model?
Zero-trust is a security model based on the principle that no user or system should be trusted by default, even within the organisation's own network. Every access request is verified regardless of where it originates. In practice, this means enforcing authentication for internal service-to-service calls, applying least-privilege access for all accounts, and continuously monitoring network traffic for anomalies. It is the standard approach for cloud-native and distributed application architectures.
What should be in a software development incident response plan?
An effective incident response plan should define: who declares an incident and at what threshold, who leads the technical response and communications, immediate containment steps for the most likely breach scenarios, automated alerting thresholds, communication protocols for users and regulators, and a post-incident review process. The NIST SP 800-61 framework provides the standard structure: preparation, detection, containment, and recovery. The plan should be tested through drills before it is needed, not filed and forgotten.
