Our DevSecOps ToolsHow we use DevSecOps tools for Continuous Hacking
DevSecOps is a culture that embeds security into every phase of software development. As we have said in our advice on DevSecOps implementation, there are several tools that may be part of this culture in your organization. DevSecOps tools, which serve as a complement to the work of expert security testers in this approach, are those that allow you to perform diverse testing methods automatically throughout the entire software development lifecycle (SDLC). The experts perform the security testing methods manually to identify more complex and higher severity vulnerabilities and, additionally, review the reports created by the tools, which, although fast, have accuracy shortcomings. This combined methodology is quite valuable for the comprehensive integration of security while moving at DevOps speed.
In this blog post,
we'll talk about the DevSecOps tools
we use at
and how we have achieved their implementation
in our Continuous Hacking solution.
What are DevSecOps tools?
Today's software development process is fast paced. Developers need to deploy software solutions into production several times a day to meet consumer demand and keep up with the trends. DevOps traditionally places security in the testing phase of the SDLC, hunting for bugs and errors. But as soon as teams become aware of how much the threats of cyberattacks can hurt their organization and customers, they learn the importance of making security a part of the SDLC from the very start. This is at the heart of a culture called DevSecOps and is partly achieved by integrating manual and automated security testing into the DevOps workflow to enable security checks across the SDLC. Of course, we say "partly" because a few more things need to be achieved to fully embrace DevSecOps. (See "How to implement DevSecOps" and "DevSecOps best practices.")
Tools for DevSecOps, which complement the manual work of security analysts, allow running some security testing methods automatically. These tools are used throughout the entire SDLC and with the guidance of security experts. In addition to focusing on the vulnerabilities that represent the most significant risk exposure for a system, these experts constantly review the result reports by the tools. Combined manual and automated work yields accurate and faster results. Below, you can see a representation of the SDLC. As we've argued in another post, organizations wishing to implement DevSecOps need to define the moments for security activities. Some DevSecOps tools are therefore more suitable from a certain phase onward but one thing is notable: Most of them are put into use before the traditional testing phase.
(Image taken from here.)
Fluid Attacks' DevSecOps tools
Static application security testing (SAST)
Static application security testing is a method that can be used continuously from the code phase of the SDLC onward to look at vulnerabilities introduced in source code, byte code or the application's binaries. Our automatic SAST analyzes the source code in your repository and can help you learn quickly the severity of vulnerabilities reported in it, how much risk exposure corresponds to each of them, where exactly you need to make changes, what the recommended remediation is, etc. Our security analysts conduct manual SAST alongside our tool to find more complex, perhaps zero-day, vulnerabilities and reduce false positives and false negatives. As our client organizations' developers work swiftly on fixing the vulnerabilities we report and learn how not to introduce them again in the source code, they all start to become security developers.
Software composition analysis (SCA)
Software composition analysis is a method that can be introduced in the building phase and used continuously to look at the third-party code dependencies, from which your software may inherit vulnerabilities. Our automatic SCA does not stop at finding buggy open-source dependencies but also identifies the licenses of all open-source dependencies in your codebase. To avoid legal risk, we advise you to choose open-source with a license that is compatible with your organization's policies. As our SCA inventories the open-source dependencies in your software, it's easy to produce a software bill of materials (SBOM). In manual SCA, hackers enrich the results from the tool, verifying that all the software dependencies with vulnerable versions are reported. As you can easily guess, SCA and all the methods and tools in this blog post should be used still in production phases. For example, during the monitor phase, organizations must keep open-source components up to date and identify any threat due to criminals exploiting zero-days in them.
Dynamic application security testing (DAST)
Dynamic application security testing is a method that can be used continuously from the test phase onward. It is performed to assess a build artifact that can be deployed into staging or testing environments. Why is this? Because DAST attacks the application while it's running and analyses its response. Our automatic DAST assesses, to name a few things, whether user authentication and authorization work well and looks for vulnerabilities that would allow attacks such as injection. By combining automated and manual DAST, the simulated attacks are more clever, as our hackers create their own exploits and use their up-to-date knowledge of the techniques used by threat actors. Since DAST has no access to the source code, manual SAST steps in to complement the security testing.
Fluid Attacks' DevSecOps agent
is a component
that can be implemented
from the coding phase onward
and used continuously.
It checks the changes to the repository for noncompliance
with the organization's vulnerability acceptance policies
and breaks the build
if it finds anything wrong.
Breaking the build means
preventing a vulnerable version of the system
from being deployed into production.
This is automatic and,
as can be deduced,
customizable by every organization for each of their projects.
the organization may define
that it will have the agent break the build
only for vulnerabilities whose CVSS
base score is between certain values.
Although our DevSecOps agent works automatically,
it feeds on the results of automated
and manual SAST and DAST,
so that there's no doubt about accuracy.
Attack Resistance Management platform (ARM)
Fluid Attacks' Attack Resistance Management platform
is ready to run nonstop
from the very start of your project.
ARM is where our client organizations map
every one of their digital assets,
get results from every security testing method,
track their risk exposure over time,
receive evidence and guidance from our ethical hackers,
manage vulnerability remediation and stakeholders,
The fact that ARM not only provides a real-time inventory
of exposed and attackable software
but offers all the above
makes it more complete
than an attack surface management (ASM) platform.
Leveraging DevSecOps tools for Continuous Hacking
we integrate DevSecOps tools
into a single solution called Continuous Hacking.
In our working scheme,
developers deploy micro changes first
on their repositories,
and then our ethical hackers manually,
together with such automated tools,
seek to detect all the security issues in the technology.
In such a way,
we continuously test the latest versions of the repositories
corresponding to our clients' projects.
It's our DevSecOps agent
that we incorporate into the continuous integration
and continuous deployment (CI/CD) pipelines
to ensure that no identified vulnerability is released into production.
Thanks to our security testing scheme,
software development teams deploy technology to production
several times a day
without sacrificing speed and security.
Ready to try Continuous Hacking?
Discover the benefits of our comprehensive Continuous Hacking solution, which hundreds of organizations are already enjoying.