Let’s face it, we have a problem. Hackers are breaching organizations’ software infrastructure and applications daily. Most of these breaches are preventable, but yet they still happen in ever-growing numbers. From my experience, I don’t believe that we are investing enough in the skills of the developers who are building our software as well as the engineers who create the deployment environments. Security needs to be baked in at all levels and this includes investment in the training of an organization’s software development staff.
I believe that there are widespread assumptions about the security education of software developers who have come out of four-year programs. These off-the-mark assumptions are driving the investment in the training of an organization’s development staff. Would you be surprised to know that “More than 76% of college-educated respondents said they weren’t required to complete any courses focused on security during their higher education study.”1? Most developers (64%) learn their security skills on the job and that “a miniscule 4% said they learned their most relevant skills from third-party training.”1? “Only about half of respondents said their employers paid for any additional training since they entered the workforce.”1 Clearly, we can not assume that most software developers understand security risks in the code that they are developing.
I was surprised by these findings because as someone who was in college in the late 70’s through early 80’s, security wasn’t a big deal because most computers weren’t connected to a publicly accessible network. As the internet became available, usage expanded, and attacks became more common, I assumed that higher education would keep pace. However, it turns out that the curriculum guidelines created by the Association of Computer Machinery (ACM) recommend that someone pursuing a software engineering degree receive four to eight lecture hours of security-based training, that’s not per semester, but for their entire bachelor’s degree program. I’m stunned at this because I currently spend at least that much each month in professional study. I would not be surprised if executives who set the priorities for software development organizations are making the same false assumptions as I did.
In order to develop and deploy systems that follow a “Defense in Depth” strategy of embedding security into every level of an application, as well as its deployment environment(s), the managers, software developers, DevOps engineers, and operations engineers must have the necessary security skills.
How do we go about correcting this problem? I believe that we must begin by doing the following:
Convince leadership that security must be baked into our software products, processes, and infrastructure; that not doing so may leave the company exposed to terminal risks (e.g. witness calls for the revocation of Equifax’s corporate charter). The priorities and budget for security must come from the top.
Equip our software developers, DevOps, and operations engineers with the knowledge to do their jobs securely and efficiently and renew that training regularly because threats change constantly.
Equip our software development managers with an understanding of how application security is baked into secure applications and the controls that can be implemented to do so.
We need to recognize that our development team’s security skills may not be at the level we think it is. Addressing problems with a “Defense in Depth” approach requires talented and knowledgeable staff. The first step in solving a problem is recognizing that we have one.
The DevSecOps Global Skills Survey: https://info.veracode.com/analyst-report-devsecops-global-skill-survey.html
*American Cyber Security Management (AmericanCSM.com) is focused on reducing your risk of data misuse. We do this through our Security, Privacy and DevOps offerings, delivered by seasoned experts. We can ensure your Agile delivery processes are secured and efficient, while maximizing your investments.