In sporting events, movies, and TV entertainment, we often have STAR athletes and STAR actors/actresses. When going to school, most students strive for an A* (STAR) grade on their assignments, tests, and assessments. In this same context, is there a way for organizations to achieve something similar concerning their software security programs? At Checkmarx, we believe the answer is yes. So how does an organization implement a “STAR” program to achieve more-secure software? It all begins with organizations addressing their security programs from both a technical and human perspective as follows:
Eight Concepts of the Software Security STAR Program
From a technical perspective, a STAR program must address the following four concepts:
From a human perspective, a STAR program must address the following four concepts:
Let’s take a deeper look into the eight concepts listed above that eventually evolve into the eight objectives of the Software Security STAR Program.
All applications are built from various software programming languages, and selection of the appropriate software language is one of the most important factors as organization try to implement “security by design” throughout all stages of DevOps. Vulnerabilities do not get introduced into software on their own. They are introduced by developers during the software development process. Since most application vulnerabilities are introduced through software, it takes software to find and help fix the vulnerabilities.
Organization must realize that integrated application security testing (AST) solutions are required to detect software vulnerabilities in the code they create. These AST solutions must be capable of supporting the same programming languages that were in use during the software development process.
When an application is released with a vulnerability, most will think application security testing was not adequately performed, the tester didn’t think about a certain function, they were not sufficiently trained, or they did not know what they were doing. Although the tester may not be the same person that developed the application, when applications are released with errors, it often appears it’s the tester’s fault.
Testing applications to detect software vulnerabilities is an extremely important function that must be embedded throughout the stages of DevOps. Organization must allocate adequate time to perform application security testing and enable developers to test their own code during the various stages. However, many organizations don’t know how much time is needed, what’s expected of the testing, and who should perform testing during the development process. As a guideline, the amount of time allocated for testing should be the same time allocated for development, and developers should have access to solutions that enable them to initiate testing procedures anytime during development.
Waiting to test software until the Test/QA phase of DevOps, often introduces unwanted and unnecessary delays that cost time and money. Instead, software should be tested with automated solutions designed to operate during the Code, Check-in, and Build phases of DevOps. Plus, software should also be testing during functional testing with solutions designed to operate when the code is in its running state.
In DevOps environments, automation is the workflow that connects the different development systems, such as the code repository and CI/CD. Integrating the AST activities automatically, through the use of plugins into the different systems developers use, will help them perform the mandatory testing asynchronously, without delaying the speed of the application delivery. Automation and integration is the key to developing and releasing software at the speed of DevOps.
Most AST solutions have the ability to identify vulnerabilities in software, but just showing that vulnerabilities exist does not always provide measurable value for an organization. Instead, what they need are solutions that highlight where the vulnerabilities are located within the code itself.
The AST solutions organizations needs should provide the best-fix location to help developers and AppSec teams quickly and effectively remediate vulnerabilities, which is the actual effort needed to secure any application. The AST solutions that organizations choose will determine the effort and time required for vulnerability remediation, and they should measure the value of the AST solutions based upon the speed of the remediation effort.
Obtaining buy-in from the management team will determine the success of any software security program. Acceptance of and willingness to actively support and participate in a program that improves the security of the software organization’s release is critical.
Every team member including developers, DevOps engineers, R&D, AppSec teams, and consultants, etc. must buy in and learn to fully collaborate between the various groups to fully achieve the main objective, which is to deliver secure applications for their organizations.
Training developers on secure coding practices is imperative to reducing software vulnerabilities in the code they create. Unfortunately, lengthy video tutorials, periodic and often extensive classroom training, and tiresome online courses are often the norm, yet rarely achieve the objective. In addition, if an organization’s AppSec team or consultant was unable to provide the remediation advice on specific programming languages, highlights the fact that additional language training is needed.
Organizations should propose that their AppSec teams and consultants learn at least two new programming languages every year and secure coding education should be embedded within developers integrated development environments. When defects in code are detected, developers and AppSec teams should be able to jump to a vulnerability-specific training module that teaches them how to fix a specific vulnerability. Gamified training that’s fully integrated into developer workflows delivers the best results.
One of the biggest failures of any software security program is the lack of vulnerability and security awareness. Training that builds awareness throughout an organization must be continuous and not a one-time effort.
Although developers and security teams have different objectives, they may not fully understand each other when working to deliver on the same set of goals. Building continuous awareness will help close the gap between the developer teams and the AppSec teams, allowing them to understand the challenges they face from both perspectives.
Reporting and key performance indicators (KPIs) are necessary to understand what is improving, what still needs more improvement, and what is not meeting the objectives. Without reporting and KPIs, no one will be able to quantify if the software security program is effective.
Organizations need a software security platform that tracks vulnerabilities and provides insight into the developers working on remediation. In addition, having an AppSec team who monitors the defect density metrics of the applications and maps this information to KPIs is extremely helpful. Once reporting and KPIs are in place, the results of the software security program should be reported to the management team, highlighting the positive scope of collaboration and any areas of improvement.
If organizations desire to build more secure applications and raise the trust of their applications to the highest level, following the recommendation herein will raise their software security program to what we call the “STAR” level. Nearly everyone wants to be a STAR!
*** This is a Security Bloggers Network syndicated blog from Blog – Checkmarx authored by Jason Khoo. Read the original post at: https://www.checkmarx.com/2019/12/09/raising-your-software-security-programs-to-star-level/