The document discusses implementing a static application security testing (SAST) tool. It recommends starting with a central scanning model where a security team scans code and reports vulnerabilities. Over time, the organization can transition to a full software development lifecycle model where developers use the tool during coding. Key factors for a successful implementation include choosing the right scanning model, training users, and establishing processes for fixing and verifying issues. The document also provides tips on maximizing returns and reducing costs such as licensing the tool granularly and keeping deployment and training short.

1. A successful SAST tool implementation
By Assaf Pilo – Director of Sales and Marketing, Checkmarx
assafp@checkmarx.com, Jan 2012
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?
www.checkmarx.com

2. A successful SAST tool implementation
By Assaf Pilo – Director of Sales and Marketing, Checkmarx
assafp@checkmarx.com, Jan 2012

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
www.checkmarx.com

3. A successful SAST tool implementation
By Assaf Pilo – Director of Sales and Marketing, Checkmarx
assafp@checkmarx.com, Jan 2012
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
o

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 Full SDLC, getting the development teams more involved in reviewing, and remediating the
code.
www.checkmarx.com

4. A successful SAST tool implementation
By Assaf Pilo – Director of Sales and Marketing, Checkmarx
assafp@checkmarx.com, Jan 2012
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.
www.checkmarx.com