The SAST process should always be included in the context of the S-SDLC to correctly validate the code’s goodness in terms of security.
Checking the quality of the code developed is complex and, above all, expensive for any company. The main vendors offer valid technological solutions with different peculiarities to satisfy this need.
Instruments are valued by the market compared to several features, such as:
-
language coverage;
-
compiled scan;
-
fewer false positives even through the application of AI;
-
integrability with CI/CD tools;
-
integration with Software Composition Analysis (SCA) engines;
-
reporting according to the main benchmarks and/or certification bodies;
-
differentiation of offering with respect to consumption or perpetual license models
The technological aspect, however, is not the only element to consider: the process is equally important. Is it useful to have the best performing car if it cannot be used and valued by a capable team of mechanics and drivers?
Synergy between tools and users is also essential in this area, as well as the ability of people who develop the code and verify vulnerabilities.
The traditional SAST (Static Application Security Testing) process should always be declined and included in the context of the S-SDLC (Secure - Software Development Life Cycle) of the organization to get the right results. Whatever the development model is, waterfall or agile, or in the presence of a Devops or legacy context, it is essential to involve the tool in the most appropriate phase of the software life cycle.
Secure - Software Development Life Cycle: un esempio
Let’stake as an example an adoption model in a context of fast-reiteration, typical of agile models.
The model represented is characterized by a strong mediation of prioritization and the planning of remediation by the project manager to avoid the classic blocking "gate" and to leave the responsibility of the residual risk to the business.
The security team is involved to ensure the consistency of the results obtained by the technology to avoid the downstream management of false positives or vulnerabilities characterized by an incorrect risk assessment. Any self-respecting process should be measurable: it is necessary to implement KPI to assess the performance of the vulnerabilities resolved and reintroduced.
Last but not least, the issue of training: some organizations impose a classroom training to the teams involved in development. Sometimes, this training could be ineffective, because it is carried out on literature material and generic examples. For this, other organizations give direct access to SAST tools to the personnel involved, to fully exploit the information accompanying the vulnerability and give way to "learn by doing".
Our approach
Kirey Group makes available to companies the ten-year experience in technology and process, thanks to customer projects and in-house projects.
The DevSecOps team has the cross-field skills and experience to offer advisory, system integration and process consulting. A typical SAST project can involve champions figures with security and development skills.
The main phases are:
- Assessment of the current S-SDLC process
- Identifying the most suitable technology to meet customer requirements
- Demo/POC
- Definition of project, stakeholders and milestones
- Implementation of technology
- Review of the existing process with the definition of new operating procedures
- Tutoring
-1.png "002-Kirey Group - una riga - (color)-1")
