A secure software development life cycle means baking security into plan, design, build, test, and maintenance, rather than sprinkling it on at the end, Sara Martinez said in her talk Ensuring Software Security at Online TestConf. Testers aren’t bug finders but early defenders, building security and quality in from the first sprint. Culture first, automation second, continuous testing and monitoring all the way; that’s how you make security a habit instead of a fire drill, she argued.
The Common Weakness Enumeration (CWE) statistics show that over 85% of software weaknesses come from how we implement the code, and about 60% trace back to design decisions. That means the foundation of a product, its architecture, and the way it’s built have a huge impact on how secure it will be over time, Martinez said. Once the product is live, it’s all about watching it closely, running vulnerability scans, and patching issues as soon as they surface to stay ahead of attackers, she added.
A secure software development life cycle looks a lot like a regular SDLC, but with security built into every step, Martinez explained:
- It kicks off by defining clear security requirements and running threat modeling while you’re still planning and designing.
- During development, you follow secure coding practices, review dependencies, and use security testing automated tools or dependency scanners to catch weaknesses early.
- Testing goes beyond functionality with DAST, penetration tests, and other security checks to uncover real attack paths.
- Once the product is live, you keep it safe through secure deployments, continuous monitoring, and fast patch management.
Secure software starts with culture, the same as quality, Martinez argued. It’s not a checklist, it’s about sharing responsibility across developers, testers, ops, and management:
Every company should create an action plan that fits its product, look at secure software development guidelines, and make sure security practices are part of daily work. Automation is key; introduce security analysis tools into the CI/CD pipelines so weaknesses are caught early and consistently.
Martinez mentioned not to forget the human side of testing: add specific functional test cases tied to security requirements so the team stays alert to issues like weak input validation, risky roles and permissions configurations, or access control.
Many of the biggest incidents still come from old, and many times well-known attacks, that we could prevent with the right tools and practices. Martinez said. And now we have new challenges like AI-related vulnerabilities that are reshaping the landscape:
For example, many companies are using AI to generate code, but they’re not scanning it or applying secure development practices, so they end up introducing known vulnerabilities right into their products.
I’ve learned a lot, but I know I’ll never be done learning. Security is a moving target, and security testing is an ongoing challenge, and that’s exactly what makes it such a fascinating, ever-changing world.
InfoQ interviewed Sara Martinez about software security.
InfoQ: What role do testers have when it comes to security?
Sara Martinez: Testers are one of the best secret weapons we have for security. I think our role goes way beyond checking if a feature works; we’re in a perfect spot to notice the little things that can turn into big vulnerabilities, like weak input validation, risky roles and permissions configurations, or access control.
Teams need to share security responsibilities in the Security Software Development Life Cycle (SSDLC), like challenging security requirements, helping with threat modeling, and running static and dynamic security automated scans to catch issues early. Testers can keep security alive in the pipeline by making sure fixes are verified quickly and integrated into CI/CD.
InfoQ: What data do we have on vulnerabilities and weaknesses, and how can we use that data?
Martinez: Standards with data like CWE (Common Weakness Enumeration) and CVE (Common Vulnerabilities and Exposures) give us a shared language for describing software weaknesses and real-world exploits. This data isn’t just for reports; automated scanners actually use these references to detect vulnerabilities in code and running applications.
I think it’s also a great way to spot attacker trends. In the last few years, the top CVEs have been dominated by issues like cross-site scripting (XSS) and SQL injection, which continue to hit a huge percentage of software products. Using this data helps teams prioritize testing, focus on secure coding practices, and stay alert to what attackers are really exploiting.
