The average cybersecurity professional, particularly the average CISO, is unlikely to be or have a background as a software developer.

According to one source, as few as 10% of CISOs have backgrounds in software engineering. This makes sense when you consider that not many people enter a career in software development thinking: one day I’ll be a CISO?

It is understandable, then, that cybersecurity incidents due to poor security implementation at the development phase are common (for example, this paper suggested that up to 43% of security errors are made during development) – not all developers have benefitted from being trained and educated with a cybersecurity focus. Some were trained in organizations where, at the time, software engineering focused more on features and functional aspects such as algorithms, data structures, programming languages, rather than security.

The Software Development Life Cycle (SDLC) has been in use since the 1960s, as a structured approach to software development it should be well understood, or at least recognized. Nonetheless, it took another 40 years before the concept of Secure SDLC (SSDLC) came about. Many consider 2002 to be its birth date, thanks to the inception of Microsoft’s Trustworthy Computing Initiative that year.

Adoption and Use of SSDLC

More than 20 years later, we can be comfortable that SSDLC has come of age. The changing cybersecurity landscape doing much to advance it from a concept to maturity. The adoption process can be a slightly lop-sided model, though, which means we have to come at it from two different directions.

The first direction is for the cybersecurity team to guide the security efforts of the development teams. researching SSDLC will quickly bring up the term “shift left”: if we are beginning to consider security requirements for new developments fairly late in the process, we must try to push that consideration “to the left” – that is, much earlier in the development timeline. Note that we were very careful to use the term “guide” a couple of sentences ago: the cybersecurity team cannot simply do it themselves, but instead must engage the various teams and stakeholders that are responsible for all elements and stages of development. The CISO is at the top (and will be most aware of this approach). The person responsible for application security must work closely with anyone who is making new applications that they will ultimately be responsible for. The software architect must introduce security considerations from the initial design phase. The business analysts must be mindful of security requirements (and work with the users to figure out how usability and security can be good neighbors). The testers need to comprehend the security requirements and develop the means to test against them. The developers need to buy into this as well … in fact that is the most critical requirement.

It is essential for the cybersecurity team to lead SSDLC, because they are best placed to know and understand why it is needed and how it fits the business. They are also closest to sources of threat intelligence and information about new attack types and major vulnerabilities. The CISO cannot make a piece of software secure, though: that is the developers’ job. The thing is, there are usually many ways for a developer to implement a particular requirement, some of which may be highly robust security-wise but others of which may skirt around security and meet the literal wording or functional requirement, but not the spirit of the requirement. We need our developers to understand why the security requirements exist, what the consequences of a breach might be and how to do their jobs such that the risk requirements are met alongside the functional ones.

This leap of knowledge can be a big one, depending on previous focus and development priorities. Also, there is more to development security than just understanding security: there might be a requirement to learn new development concepts, or to find out how to integrate the code being written with the corporate authentication server. On top of this, though, are entirely new concepts that are not directly related to development.

Security and Testing

Testing is a big example. Concepts such as Static Application Security Testing (SAST – reviewing source code for potential vulnerabilities, preferably using automated tools) and Dynamic Application Security Testing (DAST – using tools to probe running code for potential security issues) are new to many developers, and can be non-trivial to introduce. Secure software testing forms 14% of the syllabus of ISC2’s Certified Secure Software Lifecycle Professional (CSSLP) certification, in joint second place behind secure software architecture and design (15%) and alongside secure software implementation (also on 14%). The CSSLP covers all elements of security in the software development process, from basic concepts, through requirements, architecture, implementation and testing. It also extends the concept of development into two areas that many developers may not have come across or at least may not have considered.

First is secure software deployment, operations and maintenance. The concept of DevOps (Development Operations) came about in the mid-2000s: the idea is that instead of developers writing code then passing it over the wall for the ops teams to run and maintain, the two teams would collaborate from day one, throughout the entire lifetime of the product and up to the day it is decommissioned. DevSecOps – unsurprisingly – extends the idea into security, the term entering regular use a few years after DevOps itself.

The final and highly topical concept of note in the CSSLP domain list is secure software supply chain – consideration of the security elements of things that others have written. From a development point of view, the software libraries we use are core to what developers do: it makes perfect sense to legitimately leverage something that someone else has written for the purpose, as it could save us hundreds or even thousands of person-hours’ development time that would otherwise be spent reinventing the same wheel. Developers must be cognizant, however, that if things they write might have vulnerabilities, so might things that others have written. The Log4j incident of 2021 is a case in point, where a high-severity flaw was found in a software library that was used by a plethora of businesses worldwide.

The Important Role of Secure Development

Secure development is critical in any organization that undertakes software development. It is easy to develop software insecurity, so knowledge of how to avoid the pitfalls can only be beneficial. Courses and certifications like the CSSLP can help developers fill the knowledge gaps they have in this respect and further develop their skills.

As security professionals, it also makes sense for the cybersecurity team to expand their knowledge in the software development field. Remember, DevOps brings the development team into an operational world, but it also brings the ops teams in the other direction into the developers’ space.

With DevSecOps, the Sec team are probably already working with Ops, and there is now a golden opportunity for them to get to know Dev.

Related Insights