When hearing the phrase ‘spell check’, the majority of people will automatically picture red lines under words in a word document.
For years, spell check’s process of identification and remediation has acted as a reliable companion for anyone composing a piece of writing.
There is a notable benefit to being immediately corrected, having an instant identification of an error, and then having a suggested correction to follow. Imagine applying such a process to software security.
Ready for change
Traditional working patterns for software security testing have been stuck in a rut lately. Development teams write code until the scope of a given release is completed, after which the completed application is tested.
Results are then given back to the development team for remediation. This is where the problems arise. By the time the results are returned, the development team are already well into the next development cycle.
Addressing these results requires the team to stop their current work, reflect on the previous cycle, and then investigate and remediate the findings.
Testing tools have also been known to return false positives, so it is essential that developers verify that each vulnerability is, in fact, a vulnerability, and whether it is exploitable.
Development teams frequently run on timely incentives rather than the need to be secure, thus a system of having to verify each vulnerability puts workers under pressure and proves ineffective.
Security training, where it exists, is also outdated. Developers are required to put their development cycle on hold to attend classes or participate in computer-based training.
However, as more and more millennials enter the development job force, this method of training is no longer optimal. These new workers prefer to learn gradually, so that training does not distract from their daily responsibilities.
The interactive process carried out by technology comparable to a spell check will provide development teams with a fresh, productive learning opportunity.
The tools educate the developers on the nature of common bugs as well as providing a template for eliminating them. This process delivers a much more hands-on approach to learning, resulting in higher levels of retention than the more traditional, albeit outdated, learning methods.
Furthermore, the tools provide an all-encompassing view of the development team’s security readiness, collating information about staff and their performance alongside coding with security in mind.
Managers can identify patterns and then take steps to address any underlying issues, either through additional training or individual focused mentoring.
Building security in
As tools are incorporated within the development environment, any bugs can be identified, explained and remediated while the code is being developed.
Embedding these tools early allows the development team to build security in from the beginning, saving time and money. These tools carry out a lightweight static analysis of the code, identifying common errors at the source.
There are also advanced versions of these tools which can explain the nature of the bug that has been identified, as well as how it can be exploited. Similar to spell check, the tools suggest ways to eliminate the identified bug, and some actually go so far as to fix the problem.
As developers see the bugs identified and receive guidance for remediation, the hope is that they will learn to code without introducing the bug.
With the introduction of technology that acts like spell check, vulnerabilities can be identified in real time so a developer can remediate the problem immediately, without having to wait for results and preventing a cycle having to be re-opened.
As developers see the bugs identified and receive guidance for remediation, the hope is that they will learn to code without introducing the bug, eliminating the fix and remediate the cycle completely.
Organisations using these tools have claimed a 15% increase in developer productivity as a result of quicker and cheaper testing.
The aim is simply to identify problems as early as possible so they can be quickly remediated at the source. Although not totally bug proof, if applied properly the security spell check will catch many of the problems.
This does not eliminate the need for more extensive static and dynamic testing at the end of the development cycle, but will lessen the pressure put on the development team to identify problems in the midst of a cycle.
It is clear that both software security testing and training desperately need a makeover. Vendors should now adopt the building security in approach by utilising technology that acts like a spell check for software security.
A blended approach employing testing tools at various stages in the development life cycle is something mature organisations should be looking to implement.
Doing so will result in the early identification and remediation of problems and avoid interruptions in the development life cycle, whilst raising the security competence of the development team.