Organizations today are aware of security risks they can be exposed to as a result of bad or wrong code practice. However, while awareness is the first step, being able to act is a whole other ballgame.
After witnessing more and more companies being hit by attacks based on well-known vulnerabilities, we sought to understand what’s holding organizations back when it comes to implement secure coding practices.
Checkmarx gathered a slew of professionals from organizations around the globe in the same room and asked them one simple question:
“What is holding you back from ensuring your Application code is secure?”
The group included security experts such as CISOs, Security team managers, as well as senior developers.
Among the many answers received, we noticed the biggest barrier to securing code was the same, solvable issue from both sides:
Lack of resources, processes, knowledge and education
Developers are used to being assessed by the quality of their code and the time it takes to get their code through QA. Unit tests are performed before each release ensuring functionality as designed.
Testing security is quite a different story. Security vulnerabilities usually won’t break functionality if not exploited and even their detection, with the help of code review or QA functionality tests, is still very difficult. Both the detection of the security vulnerability and the remediation are not clear cut for the non-professional eye towards security.
On the other hand, the security personnel will only receive the application, usually not including the code, for validation very close to release date. Considering no security tests were done by the developers, the security team now needs to run automated tools, or manual penetration tests to detect potential vulnerabilities in the code. Once this process is done, there is rarely time to fix the detected vulnerabilities, as the product has to be released on time.
What now? Release or Delay, risking customer dissatisfaction?
It’s clear that developers do not specialize in security. Implementing secure coding practice is a matter of education. Good developers live to learn and will definitely be very happy to increase their knowledge – especially if the end result will help in securing your code. Between daily requirements and ever-shortening deadlines it is tough to implement or attend proper security education sessions. Security personnel are always understaffed compared to their developer counterparts and might find it difficult to adequately train developers about the Do’s and Don’ts of secure coding.What about getting all of this done automatically?
Implementing Static Application Security Testing (SAST) as an integral piece of the development life cycle can automate vulnerability detection, reduce release timelines and most importantly, educate developers about secure coding practices.
- Detect vulnerabilities in real time – Rather than waiting for the end of the development cycle to test for vulnerabilities in the code, allow code to be tested for vulnerabilities at any stage of the software development life cycle (SDLC).
- In your CICD environment
- In your Source repository
- In your build server
- Report vulnerabilities as the bugs they indeed are – Vulnerabilities in code can be devastating if not detected and handled in time. Therefore, security vulnerabilities should be handled as any other functional bug with the relevant priority and severity. Making sure detected vulnerabilities are registered in the bug tracking systems is a critical part of embedding security into the SDLC.
- Remediate vulnerabilities quickly – Once detected, resolving the vulnerabilities can and should be made easy by pinpointing the problematic code and locating the ideal location to resolve the issue. In many cases, a single fix can resolve multiple vulnerabilities.
- Educate your developers to avoid making the same mistakes twice. This is the most important piece of the puzzle. Once vulnerability is detected and addressed, the developer has the ability to understand what caused the vulnerability and how to avoid the same security bug again. This approach ensures that in future projects the developer will most likely learn from his mistakes and avoid repeating them.
Educational gap is a significant barrier to securing your code