All security vulnerabilities are the result of a human error. All web application security issues are introduced by developers. Therefore, the best approach to building secure software is to do all that is possible to avoid introducing such errors in the first place instead of fixing them.
You can find several detailed guides on how to create secure code during application development, for example, the one provided by the Open Web Application Security Project (OWASP). They focus on such details as input validation, output encoding, access control, communication security, data protection, cryptographic practices, etc. Instead, we would like you to look at this software security issue from a strategic point of view.
Principle 1: Spread Awareness and Educate
In most cases, developers introduce security risks into the source code simply because they are not aware of such risks. While universities often focus on teaching such details as formal verification, many of them do not offer dedicated courses on security. This is especially the case for older developers who have taken such courses several years ago when there was no hype about security yet.
Universities also teach a limited number of programming languages so developers are in most cases self-taught, and some security problems are very specific to the programming language. For example, you won’t find a risk of buffer overflows in Java or C#. Even if the course teaches a language, it rarely focuses on secure coding in that language.
To make sure that your software development teams don’t make mistakes due to lack of awareness, understanding, or gaps in education, you must approach the issue strategically:
- Your development managers must not only be aware of security risks but they must be the driving force behind security. A developer with no security awareness can be educated but a development manager who does not realize the importance of security will never become the security leader.
- Don’t make any assumptions as to developer knowledge. Validate it first and if it’s not sufficient, provide in-house or external training sessions dedicated strictly to secure coding standards. It’s not the best idea to absolutely demand security knowledge from new hires because this will limit your recruitment capabilities greatly and developers can easily learn as they progress.
- Do realize that no matter how well your developers understand security, new techniques and attacks appear very often due to the speed with which technology is progressing. Some of these techniques require very specific security knowledge that can only be expected from someone with a full-time security-related position. Expect your developers to make mistakes and don’t punish them for it.
- Don’t keep your development teams separated from your security teams. The two should work very closely together. Developers can learn a lot from security professionals.
- Don’t assume that the nature of your software reduces your security requirements in any way. For example, even if your web application is not accessible publicly but only to authenticated customers, it should be just as secure as a public one. In general, don’t go for any excuses.
Principle 2: Introduce Multiple Layers of Verification
Even the most aware and best-educated developers still make mistakes so simply trusting them to write secure code is not enough. You need tools that help them realize their mistakes and correct them.
In an ideal situation, software should be tested using the following tools and methods:
- A code analysis tool that is built into the development environment. Such a tool prevents basic errors immediately as the developer is typing in the code.
- A SAST (static analysis) solution that works as part of the CI/CD pipeline. Such a solution analyzes the source code before it is built and points out potential software vulnerabilities. Unfortunately, SAST has a lot of disadvantages, including a high level of false positives.
- A DAST (dynamic analysis) solution that works as part of the CI/CD pipeline. Such a solution analyzes the application at runtime (with no access to the source code) and points out real security vulnerabilities. In the case of such software, performance is very important (scans are very intensive) and so is the certainty that reported errors are real (proof-of-exploit).
- Additional manual penetration testing for errors that cannot be discovered automatically, for example, business logic errors. However, this requires specialized security personnel and takes a lot of time so it’s often performed only in the last stages of the software development life cycle (SDLC).
However, security testing takes a lot of time and resources. Therefore, a compromise is often needed between the time and effort required to perform tests and the quality of the results. If such a compromise is required, selecting a fast DAST scanner that provides proof-of-exploit is the best choice.
Principle 3: Test as Early as Possible to Promote Responsibility
To attain top code quality it’s not enough to have secure coding requirements and secure coding guidelines in place along with a test infrastructure. Teams must not only feel obliged to follow secure coding principles during the development process and do so because their code will be tested, but they must also feel that writing secure code is in their best interest as well. Secure coding doesn’t just need rules and enforcement, it needs the right attitude.
A shift-left approach, such as the one described above, has many advantages, one of them being that developers realize that they’re an integral part of the security landscape. They feel responsible for code security and realize that if they make a mistake, they are going to have to fix it immediately and not count on someone else doing it later instead.
Of course, you can test your application for security vulnerabilities just before it goes into production. However, it will cost you much more than it would if you shifted left. The software will have to go through all stages again, which involves other resources, not only developers. The developer won’t remember the code that they worked on or the fix may be assigned to a different developer than the original one and as a result, the developer will need more time to find and remove the vulnerability. As a consequence, late testing may delay the release even by several weeks.
Not Just Security Policies
In conclusion, we would like you to realize that the security policies, while necessary, are not enough if they are perceived as a limitation, not an enhancement. Security begins with the right attitude when building applications. And even the best tools used to maintain security must be used in the correct way in the process so that they are perceived as helpful, not as a burden.
Get the latest content on web security
in your inbox each week.