Application security teams are challenged today with the need for a centralized view of exposure to security issues like Log4j and Spring4Shell. But an exploding set of artifacts and security tools makes it prohibitively difficult to secure the development life cycle. A universal scanner drastically reduces this management overhead and gets you started quickly.
We provide an example of a universal scanning engine with Aqua Trivy, the open source engine that powers Aqua’s software supply chain security solution.
Too many tools
The step-by-step security requirements for moving code all the way to deployment in production suggest the usage of no fewer than eight disparate security tools.
Starting with code
In the first step of the application life cycle, developers will assemble the logic of the application using a mix of open source packages and their own custom code.
Security steps 1 and 2
Open source packages will require Software Composition Analysis (SCA) to identify the open source packages and vulnerabilities inside. This analysis is also key to prevent the exposure of secrets by scanning for configuration issues, hard-coded secrets, logs, binaries, and other ways in which secrets could be leaked.
Into the build
Both custom code and open source components must be committed to a Git repository as well as a CI/CD tool. This then kicks off the build pipeline. One of the jobs of the CI/CD tool is to build a container image that will live in a repository, which itself lives inside a registry.
Security steps 3 and 4
The image will need to be scanned for vulnerabilities. Generating a software bill of materials (SBOM) gives you full visibility into the risks of the applicable third-party libraries and components used in your application, including tracking which software licenses are being used.
Deployment
Infrastructure-as-code (IaC) templates specify the physical resources for your cloud deployment in code, allowing you to ensure that your actual deployment is as originally intended. And the deployment itself, if you have many containers, will be managed by an orchestrator such as Kubernetes.
Security steps 5 and 6
The IaC templates must be scanned for misconfigurations so issues can be solved early in the code versus later in production. Kubernetes also requires appropriate configuration, so flagging misconfigurations in Kubernetes is key to reducing your attack surface.
Run
Kubernetes clusters will generally be run on cloud services.
Security steps 7 and 8
The Kubernetes clusters must be scanned again in runtime for vulnerabilities, and the actual cloud accounts also need to be scanned for misconfigurations. In the shared security model with cloud providers, it’s the customer’s responsibility to harden the cloud environment in which the applications are run.
The real impact of too many tools
The impact of too many tools in this process is felt from management overhead in the application security team all the way down to the customer experience.
A central view of risk
We spoke with one senior director of application and product security at a leading, US-based, B2B software-as-a-service company, who said that having a unified view of risk across all of these tools was so mission-critical that the company had actually taken it upon themselves to build the consolidated view across the tools. In the director’s own words,
“What I have done is combine the results, because one of the most important things for me is to present our security risks in a single pane of glass.
I had to pull from multiple resources and create our own Power BI dashboard that pulled from these resources to be able to present that to our CISO.
I’m talking three months of work and effort to get that operational.
Now we have to redo that effort for the infrastructure side.”
So even after three months of work, they’re still not getting the complete view of risk that they need.
Communicating the impact of Log4j to customers
What this additional management overhead amounted to, for this team, was a delay in understanding the impact of and reacting to a real security issue in the form of Log4j. For the same practitioner above, It took the team three days before they could even begin to provide communications to customers about their exposure to this vulnerability.
“We have no less than a dozen tools that we play with all the time.
How in the world can I present to the CISO and say, ‘
This is the risk that we have with the current security vulnerabilities?’
It’s almost an impossible task.”
For this team, the panic and the inability to provide customer communications was a wake-up call to look for a tool that could support them practically and efficiently.
Enforcing security
This team also had a growing list of SLAs from a security perspective, and the use of multiple tools meant they struggled to enforce remediation of any issues found.
“There were scans that are being done because they needed to be running the scan,
but they weren’t following up with remediation.
And so that’s the big initiative we have right now. I know it sounds too simple,
but enforcement of remediation is the biggest initiative we’re driving right now from the centralized view we have built.”
Taming management overhead and more with a universal scanner
A universal scanner means using just one tool in place of the eight tools listed in the scenario above, bringing about the following changes for application security and developer teams:
A single view of your risk is easier to create.
Ideally, the tool either provides its own reporting UI or integrates with another reporting tool for a single view of truth.
You can validate and track the progress of remediation and internal educational programs.
For example, an engineer can use the tool to do testing on their local machine, DevOps can use it to scan their CI/CD pipeline, and a cluster admin can scan running workloads. This makes it possible to see which of the vulnerabilities that were present in the engineer’s initial testing made it all the way through to runtime.
You can fix issues earlier with consistent checks across the life cycle.
For example, you could use the same ruleset that looks for IaC misconfigurations as misconfigurations in your cloud accounts. If you find a misconfiguration in a cloud account for a running workload, you can be assured that there’s an IaC rule to flag the same issue earlier in the life cycle.
It’s easier to get started with and scale security across teams.
Learning one tool requires much fewer people than learning eight tools. Context-shifting between tools is also less of an issue. Further, the learning curve will be less steep for one tool that covers a range of elements versus adding point solutions one by one over time. Imagine a scenario in which you’d automatically get the same results as you would from multiple scanners without having to know about them or configure them. That should be the experience of a universal scanner.
By supporting the changes described above in your application security program, a universal scanner could change the game for teams wanting to improve readiness for the next Log4j or Spring4Shell.
Aqua Trivy—a universal scanning engine in practice
Luckily, a universal scanner is easy to obtain. By way of example, Aqua Trivy is a free, open source universal scanning engine with an answer for each of the security requirements addressed above.
Software composition analysis and image scanning (CVEs)
Here, Trivy shows a tree of dependencies for a relevant package in an application.
SBOM
Here Trivy is showing the version of an image.
IaC/CSPM
Here Trivy is showing an IaC misconfiguration in Terraform.
Trivy is showing an IaC misconfiguration in Terraform.
Kubernetes misconfigurations and vulnerabilities in production
Below you can see the Kubernetes misconfigurations and vulnerabilities in production.
Thinking ahead to the software supply chain
But is a universal scanner enough? The truth is, when you begin the journey in earnest to move more than 20% to 30% of your applications to the cloud, your focus on risk will have to shift drastically to the end-to-end protection of your software supply chain. How do you make this shift in your security posture? What else do you need to focus on? There are even more elements to secure that, to-date, no universal scanning engine can cover.
- The CI/CD tools themselves are as prone to misconfiguration as Kubernetes or cloud accounts.
- The operating system of the CI/CD tooling is as prone to tampering as any operating system.
- Visibility into various pipelines and their risk profiles can identify large blind spots across various development teams.
- The health of the open source codebase can help you make informed decisions about new applications and services.
So, does this have to mean more tools? Not necessarily.
Aqua Trivy powering Aqua Software Supply Chain Security
The open source Aqua Trivy universal scanning engine powers the Aqua Software Supply Chain Security (SSCS) solution, extending the benefits of a universal scanning solution even further. This means you have one place to reduce the biggest risk. The SSCS solution is not open source, but it is built on the open source innovation and it is available via a free trial. For an open source tool specific to software supply chain security, try Chain Bench, which you can use to audit your software supply chain for newly released CIS benchmarks.
Conclusion
Comprehensive security for your migration to the cloud doesn’t have to be onerous or difficult. Aqua Trivy is an open source universal scanning engine that you can try today to scale out your application security program or simply get started. With a universal scanner, you can continuously adding more security capabilities without adding additional overhead.
Try Aqua Trivy or, talk to sales about how it can make a difference in your application security program.
