Why Prioritize Shift-Right Testing?

A few weeks ago, we pulled some of Finite State's greatest minds into a small conference room in Downtown Chicago for a product positioning workshop, ahead of the release of our Next Generation platform and the S4 conference in Miami.

We scrutinized how we present our platform to our clients, prospects, partners, and other stakeholders. Does our positioning statement resonate? Is it accurate? Are we focusing on the right things, and the right audiences? 

We soon agreed that the Finite State platform provides end-to-end SBOM solutions and comprehensive software risk management for the connected world.

That's when the concept of shifting right surfaced, and how Finite State can support that.

That got some discussion going. What do we mean by shifting right? And why should Finite State advocate starting a vulnerability management program with a shift-right approach? How can shifting right expand visibility into a portfolio? How does advanced binary analysis support all this? 

It quickly turned into a heady discussion. 

So, how does shifting right make sense? And how does Finite State help it make sense for your vulnerability management program? I'll spare you the details of the rest of that workshop discussion and just give you the outtakes. (You're welcome.)

Why Shift Right on Testing? 

What does it mean to shift right on testing? What does shifting right look like on the ground?

At workshops, meetings, and inside Finite State generally, one of the things we talk about is testing on the right or shifting right versus the traditional concept of shifting left.  

That raises some eyebrows. 

Let's set one thing straight. We'll never recommend performing no testing on the left side of development.

In other words, don't test only on the right.

But hear us out: There are advantages to waiting until the end of development to test. When you test the final artifacts, you're testing the artifacts that you're shipping--and those are the ones that matter. 

When you shift right on testing, you know nothing has changed between what you are testing and what your customers are getting. 

Conversely, when you test earlier in the development life cycle, you might miss software that been introduced during the build process, the testing process, or the integration process. Any of that software may have introduced changes, changes that you'll miss unless you're testing at the right--later in the development cycle.

A holistic product security program does testing and security work throughout the lifecycle, including at the end of development. 

Shifting Right Makes Sense - Why Doesn't It Happen More?

The reason we don't see more shift-right testing is ... it's a lot of work. Historically, testing binary artifacts has been a very manual process. It's hard to take a binary that's been compiled, stripped, and turned into something that can be executed on a computer or device and reverse engineer it to the point that you can analyze it and test its security properties. 

Historically, that's taken time, expertise, and resources. And that means that testing binaries has been largely relegated to manual pen testing efforts. Asking a security team to hack into a product isn't very scalable. You can't do that every time you have a new build of your software. That gets time- and cost-prohibitive fast. 

Scaling Binary Analysis with Automation

With new advances in binary analysis from solutions like Finite State, you can test every new build and every new release. You can test what you're sending to your customers. And when you shift right, you know that what you test is what you ship.

There are a lot of reasons to do that, but you don't want to neglect testing throughout the process either. Here's why:

Shift Right, But Shift Left Too

If you only test at the end, you're going to have a fairly underdeveloped product security program. You'll incur a lot of costs in finding bugs and security issues too late in the process. You'll have a lot of rework returning to earlier stages in the development process.

The best security programs incorporate a mix of security analysis that happens during the design, development, and build stages. They integrate component-level testing and final verifications and testing, all the way through to the end of the development process. 

The best security programs integrate SBOMs throughout development. When you use SBOMs throughout development, you can catch license violations or security issues and potentially vulnerable or compromised components early-on in the development or design processes.

You can also make sure that you have the right final checks at the end. That helps with compliance too. When you have a regulation that's mandating the use of SBOMs, you can (and may need to) assert that what is in your SBOM is what you're actually shipping. It's easier to stand by that SBOM if you know that it matches what you've shipped, rather than what you envisioned building at the outset. 

SBOMs generated at the end of development can serve as the ground truth of your product before you ship it off to your customers.

Two Weeks Later, A New Platform Release!

With Finite State's Next Generation Platform, you get the industry's only end-to-end SBOM solution within the industry's most comprehensive software supply chain security solution. 

Two weeks after that product positioning workshop in Chicago, we released our all-new version of the Finite State platform. Its new features and new data analysis capabilities support and automate your holistic product security program so you can shift right and shift left, and have the ability to scale so that you can effectively and efficiently manage risk across your software supply chain.