Platform vs Best-In-Breed

Battle of the tools in Application Security

Tool sprawl contained

I enjoy spending time working on building projects and fixing things around the house. I’ve done projects big and small. Some take weeks, some take hours. Over the many years of tackling these projects I have accumulated a vast amount of tools. Some of these tools are for very special edge case work like the tile cutter I have that I’ve used once, and not likely to ever use again. Tile work is not enjoyable. Then there is the power drill (okay all three of them) that get fairly frequent use. And the drain snake that, unfortunately, gets used once in a while. The most difficult part of having a work area full of tools? The one you are looking for is sometimes buried in the pile of other tools. This is a huge headache, especially when time is a factor.

What does this have to do with tech and security? A defense-in-depth model requires a diverse set of tools that can be used in specific instances and phases of a lifecycle. SAST (static application security testing) works great in identifying vulnerable code in codebases. SCA (software composition analysis) can help pinpoint risks associated with open-source and third-party components in an application. But as an organization matures its AppSec program, they’ll soon discover that there are a lot of niche products that cover specific stages of the SDLC (software development lifecycle) but few can cover a wide range of use cases.

The Best-in-Breed Conundrum

The cybersecurity market is vast with new vendors coming on the scene on a regular basis to tackle problems in unique ways. Some of them gain traction with a small number of customers, others get purchased by the bigger vendors and incorporated into the fold, and still others just don’t survive. This vast amount of tooling leads to “tool sprawl” where teams will identify a multiple tools to deliver specific functionality. These teams will incrementally add additional tools to tackle other parts of the development pipeline as the needs (and budget) grow.

And if you dinn’t already know, the lead time to purchase a security tool can be long. It requires a lot of convincing inside and out of the security team, and often there is a drive to get the best-in-breed. Afterall, why pay for a tool with limited exposure and clientele when you can go by word of mouth from trusted partners or utilize a ranking system from a research and advisory firm that specialize in evaluating technology vendors. Nobody has every been fired for buying the upper-right of the Magic Quadrant.

Over time, these tools add up in both operational and capital costs as well as the overhead of maintaining and integrating multiple tools.

As an AppSec program leader, you may find that your staff is ill-prepared to handle all of these tools requiring upskilling of some of your staff or purchasing professional services from a vendor. This fragmented approach also has a few other downsides:

• Integration nightmares: Each tool has its own interface, terminology, and severity ratings.

• Incomplete visibility: Vulnerabilities fall through the gaps between tools.

• Alert fatigue: Developers face an overwhelming flood of disconnected findings.

• Workflow disruption: Security becomes the dreaded bottleneck rather than an enabler.

Just like a messy workshop where finding the right tool for the job requires digging through the pile of tools from the previous jobs, tool sprawl can soon become a morass of wasted resources instead of moving forward on the actual job.

The Platform Play

I’ve spent a fair amount of time in the software security space, and I know this tool sprawl issue firsthand. Both managing staff and budget around a growing set of tools can be complicated and you very soon lose sight of the capabilities in the tools you already have. As vendors add capabilities to their tools, you become less aware of the new capability overlaps with existing capabilities you already have. Out of everything that comes with managing an AppSec program, this was one of the things that bothered me the most.

AppSec platforms like ASPM (application security posture management), while still relatively new to the scene (2023-ish), represent a fundamental rethinking of how we approach software security. Instead of assembling a collage of single solutions, organizations are increasingly adopting unified platforms to provide coverage across the entire software development lifecycle.

Modern ASPM platforms, such as Xygeni, deliver end-to-end protection across the entire software development lifecycle through several integrated components:

• Real-Time Visibility and Asset Discovery: The ability to automatically identify and catalog software assets across development environments such as repositories, CI/CD pipelines, registries, and cloud environments is a fundamental baseline of risk management.

• Intelligent Risk Prioritization: With a clear picture of your total assets, your ASPM should provide the ability to focus on the critical vulnerabilities that actually matter. This helps to reduce alert fatigue that undermines many vulnerability management programs. Your ASPM should provide an engine that is used to consider multiple factors including severity, exploitability, proximity to production, and business impact.

• Streamlined Remediation Workflows: Context around security findings helps developers resolve them appropriately. A good ASPM will deliver remediation guides and even provide checks during a pull requests. These platforms can actively block vulnerable code, unsafe configurations, and risky components from entering the pipeline.

• Malicious Code Detection: An ASPM platform can detect malicious code in dependencies allowing them to reduce the threats found in the software supply chain before they can cause damage. Even better, a solid ASPM tool will automatically quarantine affected components, limiting potential breaches.

• Ecosystem Integration: Reducing one of the most frustrating parts of buying a new tool is the ability of ASPM platforms to combine built-in security scanners with third-party tools, integrating reports from SAST, SCA, and other solutions into a unified security dashboard.

• Comprehensive Audit Trail: A good ASPM platform will maintain detailed timeline analysis of risks and security events throughout the SDLC. When it comes to root cause analysis of security incidents, this is invaluable.

The most effective ASPM platform will span the entire software security ecosystem integrating functionality with modules for specific tasks like code and OSS security, CI/CD pipeline security, secrets scanning, and infrastructure as code (IaC) security, all working together as an integrated system rather than disjointed set of solutions.

I had the opportunity to take a look at Xygeni as one of the prominent ASPMs on the market. They offer a free trial that I was able to use to play around with a simple scan. It’s free and it’s easy to set up and get going. Within a few minutes I was able to connect it to my WebGoat repo in my GitHub account and run a scan.

After making my coffee I returned to see a few hundred findings in WebGoat (no surpirses there), but the best part with an ASPM is that I can see all the areas that are impacted and where they came from (IaC, secrets, code, etc.)

If you want to take a look at Xygeni's free trial to play around with it yourself, check it out here.

So, which one is better? Like everything in life: it depends. Budget constraints, compliance and contractual requirements, team size and skill set can all be factors into why an AppSec program would choose a platform over a set of tools or vice versa.

Shifting Left and More

“Shift left” has been a term that has been used for many years to signify the desire to move the processes and tools of software security earlier in the development process. However, the AppSec space has been moving more towards a “shift everywhere” approach that embraces the reality that the security of software needs to be holistic. When thinking about the platform vs best-in-breed decision, the everywhere-all-at-once approach means integrating security along the entire pipeline. Your ASPM should shift left by being able to:

• Have integrated code scanning that catches vulnerable code and enforces standards.

• Include pre-commit scans that prevent vulnerable code from entering the repository.

• Integrate with the CI/CD pipeline to automatically block high-risk vulnerabilities.

When evaluating an ASPM platform, keep in mind that one of the goals is to move security closer to the code developers by providing consistent feedback regardless of the testing methodology (i.e. SAST, SCA, etc.) You want your teams to work inside a single platform and avoid the messiness of multiple tools or a custom dashboard. But we all know that vulnerabilities don’t go away once the code is in a source code manager (SCM). Utilizing an ASPM you can tighten the security screws in the SCM in order to get a more secure end product. To this end, an ASPM should:

• Identify malicious dependencies and code in open-source components and third party libraries.

• Focus on insecure configurations, pipeline security, and software supply chain security compliance.

• Identify and prevent secrets (keys, passwords, etc.) from being included in code, builds, and delivery actions.

• Ensure security and integrity of IaC (infrastructure as code) templates to prevent vulnerabilities in deployed infrastructure.

• Enable continuous artifact verification and integrity, while enabling attestation without slowing development.

• Provide real-time detection and alerting of suspicious activity that may indicate attacks.

When an ASPM is integrated throughout the software development life cycle, you begin to build that holistic view of your security vulnerabilities and the potential risks to the overall product. For instance, an ASPM can:

• Provide visibility into potential risks by automating the discovery of software assets and ensuring third-party components meet security standards. This allows the team to develop security controls early in the planning phase and design them in from the start.

• Actively monitor code during the development phase and pull requests. This will flag risks in real-time, automatically resolve vulnerabilities in open-source components, detect malware in dependencies, and prevent secrets from making it in to your SCM.

• Utilize IaC security scans to identify misconfiguration in cloud and system architectures while leveraging SCA to ensure third-party components remain secure after deployment, and continuously scans for new threats during the pre and post deployment phases.

The best part? ASPMs can provide you with the ability to generate attestations and verification of a secure development environment and pipeline by being able to gather evidence throughout the stages of development, build, and deploy. This is extremely helpful for those looking to provide proof of their supply-chain security through the generation of SLSA provenance and in-toto attestations.

Why I Think the Platform Play Works

There is no right or wrong answer on which is the better choice, but if I had to start over on an AppSec program and had a green field, I would choose the platform play. Modern software is joined together by multiple layers of code, APIs, 3rd party services, and external components. This means that we don’t have one piece of software to protect, we have a full product. And we need a platform that can integrate security across that product lifecycle.

While vendor lock in is a serious consideration, especially with the length of time it takes to migrate to new tools, and concerns around a single point of failure are valid, I believe that an AppSec program can be built with sufficient redundancy to manage that concern.

One method is to ensure that the ASPM vendor that has been chosen not only meets your needs, but also is able to sustain in the market for the long term. The ASPM should also show how their roadmap is going to meet future needs. Secondly, it’s okay (even encouraged) to have open source AppSec tools on deck that can cover security gaps while you locate a replacement. You are unlikely to face a situation where your vendor disappears overnight, and you are scrambling to make a tool change.

There is also the concern that a single platform may lack the innovation that a best-in-breed product might offer. However, most platforms are acutely aware of this limitation and work to build in the features and functionalities that are emerging.

With all that being said, platforms like ASPMs offer some efficiency that are hard to pass up and come from a well-orchestrated control plane that takes a product centric approach to security that offer:

• Consistent security visibility across the entire application portfolio allows the team to resolve vulnerabilities more efficiently across a product line.

• Persistent risk tracking that follows the products through their lifecycle and helps to reduce risk before they reach production.

• Business context integration that prioritizes vulnerabilities based on actual impact and reducing the alert fatigue that can come from multiple tools.

The question of platform versus best-in-breed ultimately comes down to whether you have the theoretically best individual tools or a more cohesive security program. While there's no universal right answer things like budget constraints, compliance requirements, team capabilities, and existing investments all influence the decision.

Application security platform such as ASPMs deliver what fragmented security tools struggle to do: provide unified and consistent visibility across your entire application portfolio. Like organizing a chaotic workshop into an efficient system, consolidating to a well-integrated platform doesn't mean sacrificing capability, it means gaining efficiency, context, and ultimately, a better security program.