Time for a change: Elevating developers’ security skills
Organizations don’t know their software engineers’ security skills because they don’t assess them in the interview process. Trying to do that in an interview is challenging, of course, given the time it takes for a proper assessment.
However, given the industry push toward shift-left, it’s just not good enough – for the developer or the organization – to simply view security as a teachable skill and move forward with the same processes. Given the right tools, developers at every level can achieve accelerated cybersecurity expertise as soon as they’re onboarded.
Code security progression
Let’s first establish the steps toward code security progress for engineers. These are the five levels of proficiency on which we’ll benchmark:
- Understanding risk and consequences – to know why a vulnerability is a problem, its ramifications, and its waterfall effects
- Crafting secure code without vulnerabilities – the ability to write and commit clean code
- Ability to sensitize or raise awareness – the person’s ability to raise attention within their team through emphasis and education
- Define/lead security processes and strategy – the ability to conceptualize and implement cybersecurity programs at a departmental level
- Coach – the ability to instill a culture of security from the organizational level down to the individual employee.
These levels present a clear measure of security effectiveness and tangible evidence of a developer’s own progression of security knowledge.
Where we are
All except the largest, most mature companies don’t incorporate cybersecurity proficiency into the career ladder. Cybersecurity is often viewed as a skill that can be acquired and as such isn’t a skill developers are required to have; so we first need to establish where engineering teams are in that progression today. The below matrix shows where the industry is, with positions grouped into four categories.
Current developer code security progression
With detection and remediation tools trivializing code security in the same environments they trained with, it’s not unreasonable to think that junior engineers could maintain the ability to perform this basic task as well as maintain an understanding of the risks and consequences of the vulnerabilities they create as they draft code.
For mid-level engineers, given the increased security proficiency earlier in their careers, it can now be expected that it’s their responsibility to necessitate code security with their engineers, before it is even reviewed by senior developers.
Senior developers are now free to take on the mantle of choosing and deploying security technology for their team as well as acting as a security coach, fostering that culture of security across their department.
For tech leads, all of their more tactical responsibilities are now offloaded while they maintain oversight of the entire department. However, in an extraordinary shift, they can now take a proactive cybersecurity posture and fortify their teams’ code security programs for the newest vulnerabilities – and even look to shore up other parts of the attack surface that developers interact with.
Where we could be
Given that cybersecurity tools built specifically for developers are finally being made available, we should see a fascinating shift in code security knowledge very soon.
Developer code security progress as it could be
With detection and remediation tools trivializing code security in the same environments they trained with, it’s not unreasonable to think that junior engineers could maintain the ability to perform this basic task as well as maintain an understanding of the risks and consequences of the vulnerabilities they create as they draft code.
For mid-level engineers, given the increased security proficiency earlier in their careers, it can now be expected that it’s their responsibility to necessitate code security with their engineers, before it is even reviewed by senior developers.
Senior developers are now free to take on the mantle of choosing and deploying security technology for their team as well as acting as a security coach, fostering that culture of security across their department.
For tech leads, all of their more tactical responsibilities are now offloaded while they maintain oversight of the entire department. However, in an extraordinary shift, they can now take a proactive cybersecurity posture and fortify their teams’ code security programs for the newest vulnerabilities – and even look to shore up other parts of the attack surface that developers interact with.
What does this all mean?
For this effort, developers get a pretty substantial boost to their skill set with this deepened security knowledge, which can be very valuable given the current state of affairs for hiring cybersecurity professionals with a dearth of talent available, growing backlogs, and increasing cybersecurity risks in number and scope.
Most importantly, they can achieve it without sacrificing productivity – detecting and remediating vulnerabilities can be done as easily as spellcheck finds spelling errors, and training can be short and tailored to what they’re working on, all within the integrated development environment (IDE) they work in every day. In fact, tools like these are going to accelerate workflows by almost completely removing the need for after-the-fact remediation, allowing the software development lifecycle (SDLC) to flow more quickly.
In addition, organizations can finally achieve the vision of true shift-left by integrating security into every level of the SDLC and adopt the culture of security they’ve rightly been clamoring for.
Mid-level security expertise now also becomes the baseline minimum for cybersecurity knowledge within their development teams, raising the floor of cybersecurity knowledge substantially and further making the SDLC more secure.
What comes next
For any of this to happen, the industry needs action that matches the rhetoric. If cybersecurity responsibility is shifting-left and organizations are creating a culture of security, then they need to make available the tools, education, and resources needed for those engineers to not only survive, but thrive – and it needs to happen by augmenting and enhancing developers’ existing workflows, not forcing good processes to change.