Central Scanning is the best way to begin using a Static Application Security Testing (SAST) tool.
The main effort is in installing the system and training a few selected people, primarily the security team. Productivity is immediate, as the tool begins producing audit reports soon after the installation is completed.
A Central Scanning model can be implemented and used in 2 modes:
- The security engineer centrally scans the projects for all development units.
- Automated scanning; scheduled scans and/or automated build scans.
In a Central Scanning model, developers can review results either by using the tool’s IDE plug-in, client, or different report formats.
It should be decided whether the developers receive raw results, or alternatively, after someone has reviewed, prioritized and forwarded a customized report for them.
Key elements for a successful central scanning implementation
- Rapid and effective deployment and training - It should take no longer than 3 days to fully install the system and train a handful of users.
- Simple installation and connectivity – a SAST server which is IDE indifferent and platform independent, allows scanning different languages without installing and updating the different compilers. All that is needed for scanning is access to the source code repository.
- Ability to scan non compiled code – allows simple scan setup, without the need to contact and communicate with the developing teams in order to obtain the different project components (DLL’s, JAR’s, libraries etc.).
- User friendly UI – using the same UI for all the different languages makes life easier, especially if a web UI is used, in which case you do not need to install any client or change your end-users PC image. A web UI also permits the running of the tool from any operating system.
- Building an effective workflow - one which defines the organization’s security policy, best coding practices, scan schedules, remediation policy and responsibilities.
There are different approaches to Central Scanning, but here are some of the recommended basics:
- Choose no more than 5-10 applications to scan for the first 2-3 months. You will find it easier to review and discuss the results (you should have plenty on your first scans) with the development teams or projects.
- Scan both projects and security issues, from high priority downward:
- High priority applications -> low priority
- High risk vulnerabilities presets → medium threat → low threat → best coding
- Train the developers and make sure they are familiar with the scanned vulnerabilities, as well as with the tool and the way results are presented.
After you have accumulated some mileage with your SAST tool in the Central Scanning model, it’s time to consider a complete Secure SDLC, getting the development teams more involved in reviewing and remediating the code.