Are SAST and SCA Enough for You?An automatic process that could prove to be limited
Sebastián Revuelta’s webinar is a kind of practical conference in which the author presents one of the applications created and used in his organization. We will take and present some of the information that is relevant to us.
Revuelta opens with the question “why do we need security analysis?” In view of this, he gives an account of how the number of vulnerabilities has been increasing in recent years, which can be explored and used by hackers to do damage to organizations' systems. Hence, the answer to the question ends up being: security analysis is necessary to find security flaws in the system and prevent attacks by malicious hackers ASAP.
There are different software analysis techniques
that we can employ to find vulnerabilities.
In a previous post focused on fuzzing,
we had already mentioned
SAST (Static Application Security Testing)
DAST (Dynamic Application Security Testing) techniques.
The former, as Felipe Gómez (LATAM Manager of
suggests in a webinar,
is the one we can apply
from the moment our software developer releases the first line of code.
The latter technique is the one we can apply
when the developer has already built a functional environment with the code.
At this time, we include another technique called
(Interactive Application Security Testing),
which as a main difference with the two previous ones,
has its activity or operation within the application.
In this technique, the code is analyzed
while the application is being executed.
IAST, we can interact with the functionality of the application,
either manually or automatically.
Additionally, there’s a technique called
SCA (Software Composition Analysis).
This is nothing more than an extension of previous techniques,
which Rafael Ballestas had already told us about,
and which is aimed at Free and Open Source Software (
specifically at the elements of this type
that are part of a particular application.
This is an automated process for reviewing policy and license compliance,
version updates, and security risks.
Parenthesis: When we talk about
we mean software shared openly on the Internet
that can be used and altered in its code in any way by anyone.
For the handling of all the aforementioned types of analysis,
Revuelta refers to an Application Security Testing Orchestration (
to be performed on a single platform.
However, within his company,
ASTO is only oriented
to the management of
SCA techniques and their results,
referring to the security status of the software in evaluation.
With the application presented by Revuelta —the Kiuwan Local Analyzer— the client’s source code is analyzed locally, on his company’s network. Then, the encrypted results are sent to the Kiuwan cloud.
Once the client runs the Kiuwan app on his system,
he can choose one by one the applications to be analyzed.
SCA can be performed individually or together.
The program can be opened several times at the same time
to make analyses of different applications
since the interface scans one at a time.
Within the options, the client can also delimit the language or languages
to be analyzed according to the files under evaluation.
The analysis, it should be noted, is an automatic process of the software.
Kiuwan’s app also has the option to delimit an "analysis scope," which can be: 1) baseline, 2) complete delivery, or 3) partial delivery. Baselines and deliveries are described as two different types of analysis. The baseline analysis is run when we want to get an image of a software version. We can make a comparison between a new version of the software and the previous versions. We can see whether or not we have improved the security of the software. We can tell whether or not we have repaired the defects. With this analysis, we obtain an evolutionary record, positive or negative, of the software in question.
Once the developer has made some minimal changes to the software to be analyzed, the recommended security analysis for this case ends up being the delivery one. The Kiuwan application will tell us if that delivery is accepted or rejected, according to some security gates or checkpoints previously configured, to be integrated into the baseline or the master version. The results of all analyses are presented to users on the Kiuwan website.
All the analysis processes mentioned so far with Kiuwan’s application can also be performed from the command-line interface. However, in this blog post, we are not interested in an in-depth description of its process.
We think it’s important at this point to highlight a couple of things:
Maintaining only the
SAST type analysis process
(or just combined with
and only in automatic, can be problematic.
SAST often models the behavior of the code inaccurately
and therefore tends to lead
to high rates of false positives and false negatives.
SAST should be a part of a complementary process.
SAST should not be performed just from a tool.
The automatic procedures must act very well,
but only in what we define as 'deterministic'.
Fluid Attacks, we don’t just stick with
Here we also perform
Furthermore, it is not that we hand over the work to an application or a tool
that can be useful for any type of technique.
Fluid Attacks, we extract the best possible
from automatic and manual work.
The ethical hacking service at
uses the techniques we have mentioned,
through a team of experts supported by automated tools.
As Kevin Amado —one of the hackers inside
Fluid Attacks— shares with us,
the tools automatically search and report.
The expert helps at first a little by directing the tool.
What the tool cannot find,
is in turn sought and found through human cleverness.
Also, following what Kevin reports, “tools find a percentage of the total, but in the end, it’s the human being who decides whether the tool is right or wrong.” The analysis tools save work, and although they tell lies many times, it becomes easier to determine those lies, than to look for the total vulnerabilities by hand, according to Kevin.
Other tools, not oriented to the search for vulnerabilities, serve instead for other system inspections. They are used for surveys, flow analysis, or preliminary scans. And other tools are also used to make the closing exploits; to express whether or not the vulnerabilities in a system have been remediated, and from that to allow or not the transfer to production.
ASTO process —which at Kiuwan comprises
at Fluid Attacks comprises
and is carried out on our Attack Surface Manager (
Fluid Attacks, to keep false positive
and false negative records near
we go beyond the use of automatic tools and employ human acumen and sagacity.