In the world of application security, every time you test with security tools (and you need lots of tools), it will throw up new issues that need to be managed and tracked—usually in a spreadsheet that takes time and accuracy to manage across all tools and projects. Typically, when you introduce new changes into your projects, it will then throw up newer issues which you then have to review against previous issues to check what level of priority they are, or whether they even need fixing at all.
In short: it’s a seriously arduous process.
COHERENT COMMUNICATION OF RESULTS
Alongside this core issue, there is also the wider issue of communicating your vulnerability assessment. That is to say, finding a coherent way to update, view and assess your findings with various teams and stakeholders, on projects with so many moving parts that are all updating so often.
Managers and exec teams are not going to want to trawl through a spreadsheet that houses thousands of granular findings around your tools. They also don’t want to be shown findings that are inaccurate or unnecessary, such as the same false positives, duplicates or non-issues over and over again.
You want a system that flags the important issues only, no matter what tools you use, every time you make a change. The good news is that such systems now exist and are here to make your life (and workload) a whole lot easier.
DEVSECOPS TOOLS & THEIR STAGE IN THE PIPELINE
So, without further ado, let’s have a look at some specific tools designed to alleviate your workload. There are hundreds of off-the-shelf tools to choose from, so we’ve grouped them based on particular stages in the pipeline—otherwise, as mentioned above, we’d be here for a while!
Continuous improvement / continuous development (CI/CD)
There are a multitude of CI/CD platforms out there, including GitHub Actions, AWS Pipelines, BitBucket Pipelines, CircleCI, GitLab, Jenkins, Harness and many more.
Taking Azure DevOps as an example, one of the main challenges here is the need to create lots of hooks in each pipeline to cover all the security tools. Using an Azure template to house the Uleska calls for your security toolkits makes it much easier to roll out security checks to all the projects. Azure DevOps can then show the findings from all the tools in one pipeline screen, making security decisions quicker and easier.
Find out more about CI/CD here.
Static Code Analysis (SAST) - Code or Build
There are over 60 commercial and open-source security code scanners. A good example is SonarQube—already used by many dev teams for its linting capabilities. Through the security check function, flaws can also be tracked for languages such as Java, Javascript and Python. These scans give feedback during the build/release process, spotting any new issues. We do see a great advantage in running multiple source code scanners, however, as they all find something different. Most teams run between 3-10 scanners just after the code has been built.
Find out more about SAST here.
Software Composition Analysis (SCA) - Code or Build
Late 2021 Software Composition Analysis tools have become all the rage due to the Log4Shell bug. And with so many libraries being included, checking for known issues against those versions is strongly needed these days.
OWASP Dependency-Check is a great open-source tool that scans your codeline build configuration and library files to match them against known issues. This may throw up a lot of issues - sometimes quite major ones - but you can quickly update the libraries to a patched version.
There’s plenty of commercial and open-source SCA tools available and they’ll differ in terms of their support for languages, or the vulnerability library they check against. If different tech stacks are used, we’d recommend running a bunch of these tools to see what fits best—the answer may be to run different tools for different tech stacks. This typically runs around the same time as static code analysis.
Container and Infrastructure as Code Security Testing - Build or Test
With so many teams moving to containers and infrastructure as code, you need to make sure these components don’t contain insecure configurations or known issues. Tools like the open-source Clair, which is also used by Amazon, can give you a picture of the security of your image layers, while the open-source Checkov tool from Bridgecrew scans your Kubernetes, Terraform, Cloudformation, and similar files for insecure patterns. Containers or IaC files are likely modified out-of-band to your application code changes, so these security checks will likely be added in a different place or pipeline, but still tied to the dashboard of the projects that use them.
Dynamic Application Security Testing (DAST) - Test
When the system has been deployed to staging, you can often find further issues by running dynamic security tests. Some types of security issues are better found when the system is running (instead of looking at the code).
BurpSuite has long been a favourite among security testers for its security scan against a live system. There are plenty of variables on setup, from the size of the system, to authentication, to coverage—but once set up, you can get consistent results by including dynamic testing alongside your automated functional testing.
Find out more about DAST here.
Cloud Security - Test or Release
There are hundreds of cloud security checks for all the major providers, and they are crucial to making sure the cloud setup is not vulnerable. Tools like Amazon Inspector for AWS give great coverage of both the network security and the CIS Benchmarks level of checks for the host operating systems. The only issue is the information is presented for all the systems under an account, which means work is needed to tie the issues found to individual projects—unless you have Uleska, of course!
PUTTING THIS TO PRACTICE
Should you want a bit more information about finding the right tools for your needs, download our brand-new guide: The DevSecOps Toolkit, which provides comprehensive information on how to scale your application security.
Top comments (0)