How to Make Your Software Security Program Successful

More new code is being written and deployed today than ever before. This statement will continue to be true for the foreseeable future as new applications streamline business functions, plus more of the physical world is digitised and made smart with IoT technologies. To facilitate this ever-increasing amount of code development organisations have adopted DevOps workflows to speed up the cycle from a requirement to deployed solutions. Increasingly most DevOps processes are morphing into DevSecOps workflows due to the realisation that security needs to be at the centre of every stage of the development lifecycle.

CIO's and IT departments are under pressure to deliver solutions for their businesses as quickly as possible, and with as low a cost as they can. In this pressured environment, it's likely that some aspects of security best practice will be forgotten about, or implemented weakly. This can prove disastrous financially and to an organisation’s reputation if a deployed application leaks sensitive data. There must be a robust software security program in place to ensure that security is at the heart of all development and deployment.

Checkmarx specialises in software development security and application security testing, and they have produced an excellent e-book on this very topic: How to Make Your Software Security Program Successful. The book is an excellent resource for anyone looking to put security at the core of their software development process. It details ten essential tips to consider when delivering a software security program. The e-book is available from here. We highlight some advice from five of the ten key tips below. But get the full e-book for more details on these, and the other five we don't summarise.

Renaissance partner with Checkmarx to deliver the complete portfolio of security products to make embedding security into DevSecOps easy. Contact us to find out more.

A synopsis of five of the key tips from the e-book:

Focus your software security testing on key threats - Resources are limited in development and security teams. The available resources need to be targeted at discovering and fixing the security issues that pose the highest risk. This can be done by creating a list of 3 to 5 security vulnerabilities. Then when they are fixed, repeating the process with another small list, and repeating into the future.

Give vulnerabilities the same priority as functional bugs - security vulnerabilities should be treated in the same way as functional requests and bugs in application code. The same processes followed to add functionality or fix reported bugs should be used to document and track security vulnerability fixes. Doing this ensures that the agreed small list of current security fixes is completed, rather than being continuously bumped by feature requests and general bug reports.

Make open source security testing an integral part of your software security program - Developers use existing open-source code and libraries in their application code bases. This is good as it means they are not duplicating effort already done. However, this open-source code needs to be included in the processes and program that checks source code for vulnerabilities. It can't be treated as a black box and just assumed to be safe, even if it's popular and used widely across the industry.

Automate software security as part of your development life cycle - Automation is key to DevOps processes. Adopting DevSecOps can't disrupt this reliance on automation. The security scanning and fixing need to be automated as well. Plan to implement security in a way that fits in with the existing automation processes instead of requiring a complete reengineering of the DevOps workflows. The goal is to make security as unobtrusive as possible for those creating and deploying applications. This ensures that it's going to be incorporated and effective.

Conduct security training on a regular basis - many organisations train developers and operations staff about security once a year, usually via a week-long classroom course. This doesn't fit in with the rapidly changing threat landscape that is the reality today. Training about, and how to avoid or fix, current and emerging security vulnerabilities needs to be part of ongoing day-to-day activities. Answers to security questions need to be available for immediate use from a developer’s desk. Similarly, any vulnerabilities flagged by automated source code scanners should provide links to explanations that outline the issue and how to avoid it in future.