SAST Implementation Model

Aka SCA- Secure Code Analysis

Rapid development - the issue

With rapid development in development methods, security must be able to keep paste. Old techniques of penetration testings for each release can't be applied when the application running deployments on almost daily basis. The only solution is to adapt security as well.

Static application security testing - the solution

This method when properly(more info!) implemented provides actual security benefits for both development and for security by allowing:

• Working in the same speed as development.
• Provide near real-time security issues to the developers for address them.
• Security posture of the application in scope:
  • Blocking from production (Example critical vulnerability).
  • Amount of vulnerabilities in any given moment.
  • Technical debt and current resolution time.

MANDATORY PREREQUISITES

1. Security findings must have high level of confidence (low level of false positives)
2. The process of scanning, security issues tracking and reporting is automated.

SAST implementation steps (Explanined)

!! Effort estimation are based on 1M lines of code application.

Phase 0 - Onboarding. (Done once, not a part of BAU)

* Architecture review, just ask your developers.

* More examples about threat modeling can be found here and here.

* Integration with your CI/CD, refer to SAST tool integration for api best integration, this is usually better and more flexible approach

* Integraiton with emails, sending critical and high results to development managers as status updates(speeds-up resolution time and buy-in).

This is the main step for successful implementation. It is conducted at the beginning or major technological shift for example, new DAO/new DataBase technology. The covered points are shown to the left. Failure to to go through this step results in high amount of false positives, here is an example.

Phase 1:

Requirements: Integration with identify managment system.

The main objective is to understand and identify what new false positives or false negatives were found. This is where communication between security and development is important the most, both as to assist developers on how to solve the issues and train them how to prevent the issues in the future.

Side note: Secure code awareness programs are good start, but it must be noted that they do not address programming patterns used by the organization.

Phase 2:

To get consistency and good quality results, there is need to monitor and adjust SAST/SCA rulesets in order to further reduce false positives and identify new false negatives.

Phase 3:

Requirements: integration with bug tracking system,security visibility board. Getting existing statuses and trends progress.

(For examples: when the project was last scanned, how many issues were resolved in the last week, month.)
Is this step most of the magic is happening. First, developers get actual findings into their native bug tracking system, for example Jira and development managers needs to address development efforts to resolve the issues, no more hiding behind not knowing, no time. Next, all the project statuses such as which application was scanned, what are the findings can be visible by security and development. This gives unique opportunity to to aligned security and development.

To summarize:
It is feasible to achieve good application security state even in the fasted development implementation. This approach gives enormous benefits both for security and development, by giving near real-time results and fix options.The only requirement is to understand that security needs to evolve into modern practice and not to rely on old approach.

You are welcome to join slack channel or comment below.