A successful SAST tool implementation By Assaf Pilo – Director of Sales and Marketing, Checkmarx assafp@checkmarx.com, Jan 2012

www.checkmarx.com

The development world has come to realize that the way we build applications opens the door to hackers.

We are starting to realize that it is the code itself that is enabling the attacks. It’s the responsibility of the

development team to build software that is inherently impervious to attack. Catching and dealing with

security defects earlier in the development lifecycle is much more economical than dealing with them once

the applications have been deployed.

Traditionally, the responsibility of security in development had been left to specialists who had their own

tools to provide security guidance to development. This approach, while often effective had proved costly,

and more importantly, did not easily integrate into a software team’s process. And there were technical

problems: Current static analysis tools generated significant false positive results. This further

exacerbated the problem by forcing teams to track down problems that do not actually exist.

Recently there have been fundamental changes in the static security analysis tool arena. They are

usability, efficiency and false positive reporting. These changes address the major issues that developers

have shied away from the earlier tools: These next generation tools are designed to integrate with normal

software engineering workflows, accurately report on security defects, and suggest techniques for repair

that fit the engineer’s development and testing process. These tools, typified by CxEnterprise from

Checkmarx, allow static analysis to integrate with the development teams IDEs and allow security analysis

to take place as part of their normal iterative design, code, test, and analysis process. Integrating in this

manner allows the users to solve real problems, and get smarter in the process. Users gain insight to what

secure code looks like, and how to incorporate that knowledge into future activities.

Once you have chosen a tool, you will be able to complete comprehensive code audits with minimum effort

and fewer resources. In matter of minutes you can now scan for OWASP, SANS, CWE, PCI as well as other

standards and regulations and discover security vulnerabilities.

A common question among organizations that are considering implementing a SAST tool is how to plan

and prepare a smooth implementation and be able to prevail over the expected obstacles.

In order to do so, you should be able to answer these questions:

Who should be the SAST tool owner in your organization?

What type of license, and how many are needed for your organization? How should the licenses be

distributed among the different roles and development teams?

What resources are necessary in order to deploy the tool, and how long will it take?

Which users should be trained, and what is the appropriate training level for each role?

Scan methodology:

o What scan model should be implemented? Central or full SDLC?

o Who is responsible for scanning the projects?

o Who is responsible for reviewing and fixing results?

o How do you verify that the code has been fixed according to the findings?

A successful SAST tool implementation By Assaf Pilo – Director of Sales and Marketing, Checkmarx assafp@checkmarx.com, Jan 2012

www.checkmarx.com

Results:

o How to avoid an overflow of results?

o Classification and prioritization of results (company and specific projects).

o Choosing the right scan presets (OWASP, SANS, PCI etc.).

o Dealing with “false positives” (are they really false positives?).

How can you increase the ROI and reduce the TCO?

There are 2 main scanning models:

i. Central Scanning Model – recommended for deployment phase #1

ii. Full SDLC Scanning Model – recommended for deployment phase #2

A successful SAST tool implementation By Assaf Pilo – Director of Sales and Marketing, Checkmarx assafp@checkmarx.com, Jan 2012

www.checkmarx.com

Central Scanning is the best way to begin using a 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 will

begin producing audit reports soon after the installation is completed.

A Central Scanning model can be implemented and used in 2 modes:

i. The security engineer centrally scans the projects for all development units.

ii. 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.

A few key elements are needed for successful central scanning:

i. 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.

ii. 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.

iii. 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.).

iv. 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.

v. Building an effective workflow 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:

o High priority applications low priority

o 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 Full SDLC, getting the development teams more involved in reviewing, and remediating the

code.

A successful SAST tool implementation By Assaf Pilo – Director of Sales and Marketing, Checkmarx assafp@checkmarx.com, Jan 2012

www.checkmarx.com

The Full SDLC Scanning model clearly shows that your organization has matured and is taking

responsibility by practicing secure coding throughout the coding stage. By scanning the code as it is being

developed, the organization can expect some major benefits:

i. Fixing fewer findings as the code is being developed. Once ready for release, projects will have

fewer issues to fix in preparation for production.

ii. By providing a SAST tool for developers to use, a steep learning curve is often achieved, as they

tend to better understand the vulnerabilities and their causes, as well as how to avoid them in the

future.

iii. The majority of technical vulnerabilities can be easily detected and fixed during the coding stage.

This results in fewer complex and business logic issues for regulatory audits or penetration

testing (if practiced).

Here are some of the recommended distributed scanning basics:

Train the trainers; power users on each development team. Once they will have the knowledge,

they will be able to run scans, review results and provide support to their respective teams.

Train the developers and make sure they are comfortable with the scanned vulnerabilities, as

well as with the tool and the way results are presented.

Build a clear process and security policy, so that developers understand what is expected from

them; when and what to scan, and what to do with the findings, etc.

Gradually deploy the developers UI’s, adding a few teams at a time.

Maximizing the ROI while reducing the TCO is extremely relevant in today’s economy. Some of the

factors that should be taken into consideration are:

i. Licensing costs – granular licensing model enabling low entry price

ii. Infrastructure costs – standard hardware and 3rd party software

iii. Deployment and training costs – just a few days to full production

iv. Implementation costs – flexible and quick customization process

v. Operational costs – less management and administration needed

vi. Full SDLC – enablement due to non-required build and support of partial code scanning

vii. Tool productivity – large number of scans per month, high precision and effective remediation

Checkmarx experts have implemented hundreds of systems around the globe, experiencing a large variety

of verticals, companies, development environments and organizational models.

We are more than ready to share our experience with you and your company, so that you too can

successfully deploy and use our SAST technology and improve your secure coding methodology.