Sastisfying App Security
SAST (Static Application Security Testing)
is a type of white box test
in which a set of technologies is used
to analyze the source code,
byte code or the application binaries
in order to reveal known security vulnerabilities
that can be exploited by malicious users.
A Bit of History
In his 1976 paper, Design and Code Inspections to Reduce Errors in
Program Development, Michael E. Fagan explains how to do a code review
and, thus, creates the world’s first code review process. Fagan
inspection is a formal
execution process involving several phases and participants, and also
defines entry and exit criteria to both start and end the process.
In 1992, in his article Experience with Fagan’s Inspection Method,
E.P. Doolan proposes using software that keeps a database of detected
errors and automatically scans the code for them. This begins the use of
automated tools.
Software Development Life Cycle (SDLC)
SDLC is a series of stages that must be followed for the development
of a specific software product. These stages ensure that the quality,
functionality, and objectives of the application meet customer
expectations and development standards.
Figure 2. Software Development Life Cycle stages via
Synotive.com
During the SDLC it is important to use testing methodologies in the
early stages of development that identify and resolve security
vulnerabilities quickly, before the application’s release. These
vulnerabilities can be found on the following websites:
Figure 3. OWASP Top Ten Project via owasp.org
By applying SAST
we can detect and avoid most of the security vulnerabilities
listed in the previous links’ pages.
How does SAST work?
SAST can be applied manually or through the use of automated tools.
Manual testing is done by a team of testers responsible for
reviewing the code for known security vulnerabilities. Once
vulnerabilities are found, they are reported to the development team to
be solved. Manual testing includes several stages including:
Synchronization: This stage includes receiving from the
developers the application, a complete explanation of what the
application does, and how the application does it.Review: In this stage, the testing team takes the source code
and analyzes each line, method, class, and file for security
vulnerabilities.Reporting: At this stage, false positives and irrelevant
information are eliminated, finding reports are created and
delivered to project leaders responsible for communicating with
developers, who then mitigate or patch the vulnerabilities.
Figure 4. Report of finding in manually test via
Mitre.org
Automated tools: There are many
tools that
allow us to automatically perform code analysis and provide reports of
the vulnerabilities discovered during the scanning process. Because
these tools are more flexible, they can be integrated with development
environments that include Waterfall scenarios, Continuous Integration
(CI/CD) environments, Agile/DevOps, source repositories, and even
with other testing tools.
These types of tools use sophisticated functions such as data flow
analysis, control flow analysis, and pattern recognition to identify
potential security vulnerabilities. The result is that vulnerabilities
are reported sooner, especially in complex projects or projects with too
many lines of code.
Figure 5. Report of findings in automated tests via
Oreilly.com
Reports are always checked by employees because automated tools tend to
generate a large number of false positives and need to be filtered to
extract the potential risks of an application.
As
Synopsys.com
says:
“There are six simple steps needed to perform SAST efficiently in
firms which have a very large number of applications built on
different languages, frameworks, and platforms.”
Finalize the tool: “Select a static analysis tool that can
perform code reviews of applications written in the programming
languages you use.”Create the scanning infrastructure and deploy the tool: “This
step involves handling the licensing requirements, setting up access
control and authorization, and procuring the resources required
(e.g., servers and databases) to deploy the tool.”Customize the tool: “Fine-tune the tool to suit the needs of the
organization. For example, you might configure it to reduce false
positives or find additional security vulnerabilities by writing new
rules or updating existing ones. Integrate the tool into the build
environment, create dashboards for tracking scan results, and build
custom reports.Prioritize and onboard applications: “Once the tool is ready,
onboard your applications. If you have a large number of
applications, prioritize the high-risk applications to scan first.
Eventually, all your applications should be onboarded and scanned
regularly, with application scans synced with release cycles, daily
or monthly builds, or code check-ins.”Analyze scan results: “This step involves
triaging the results of the scan to remove
false positives. Once the set of issues is finalized, they should be
tracked and provided to the deployment teams for proper and timely
remediation.”Provide governance and training: “Proper governance ensures that
your development teams are employing the scanning tools properly.
The software security touchpoints should be present within the
SDLC. SAST should be incorporated as part of your application
development and deployment process.”
Benefits
SAST can be applied in the early stages of the SDLC since it
searches for vulnerabilities in the code before it is compiled. This
ensures the least number of possible security vulnerabilities will make
it into the application before it is released.
SAST can reduce money and time costs by finding and solving
vulnerabilities in the early stages of the SDLC that could cost you
much more to fix, if discovered, in the later stages.
SAST is flexible and can be adapted to any type of project.
SAST can be fully integrated with CI/CD,
Agile and DevOps environments (DevSecOps).
Conclusions
It is important to know the security vulnerabilities
to which applications are exposed.
In order to do so,
we must continuously read and inform ourselves
via resources such as OWASP
or CWE.
Security testing
should always be performed on applications
to ensure that
they are able to maintain the confidentiality,
integrity and availability of information.
Always perform continuous reviews of an application. Security tests
should never be performed only once.
Using SAST helps programmers reinforce coding standards.
References
*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Kevin Cardona. Read the original post at: https://fluidattacks.com/blog/sastisfying-app-security/
