Quick-Fire Security Questions with Mike Hatherall
In this rapid-fire Q&A, Mike Hatherall, Lead Solutions Architect at Finite State, tackles some of the most common challenges product security teams face—especially in regulated industries like automotive, medical, and telecom.
•5:03•HD•0 views
Quick-Fire Security Questions with Mike Hatherall
Transcript
Why are software supply chain risks so difficult to manage in siloed teams?
Software supply chain risk is so hard to manage in silo teams because everybody is looking through a different lens. Engineering sees code, security, they see CVEs, compliance, they see contracts and legal, and no one's view matches the other. When you can unify those perspectives, suddenly the path to remediation becomes obvious.
What does “One Risk Picture” mean to you in the context of product security?
In the context of product security, one risk picture means to me that everybody is seeing the same truth. A single view that ties your product together, it ties your components, your vulnerabilities and any decisions you've made.
It just means that there's no confusion, there's no multiple answers to the same question, it is just a shared visibility across your entire workforce.
What’s the most common mistake you see product security teams make when trying to manage SBOMs and vulnerabilities?
The most common mistakes that I see when managing SBOMs and vulnerabilities is treating those as static.
An SBOM, for example, it's not a PDF file that kind of produce and then that's it. It's done. It should be a living document.
CVEs, they aren't kind of dealt with and never have to be kind of worried about again. You have to consider the continued scanning, you have to consider the continued change in how the product may be used, and you also have to have a way of reducing noise with all of the extra things that come in. So, the mistakes that I use, that I commonly see really are people thinking that once they have produced an SBOM or dealt with vulnerabilities, they can just mark that job as done and forget about it. Unfortunately, it doesn't work like that.
What’s the biggest advantage of using a unified platform like Finite State?
So the biggest advantage of using a unified platform like Finite State is that it normally turns chaos into clarity.
You get one pane of glass that will help you enrich your data information that you get from your component. It will help you prioritise findings with our reachability status.
It will help you provide one SBOM with high level of quality that compliance demanding, and it also means that everybody is singing from the same hymn sheet and that is the most important part.
How does Finite State help engineering, security, and legal teams collaborate more effectively?
So, finite state can help all of these teams collaborate better because everybody's operating from the same foundation.
Engineer get actual tickets, security gets governance and visibility, legal gets evidence in the form of our reporting.
It just means that it builds trust, it reduces friction and it gives everybody a very clear path as to exactly how they're going to work together by by using the same set of data from the same Platform.
How do unified risk views help companies get ready for regulations like the EU CRA?
Unified risk views will help with regulations like EU CRA, for example, because they give you traceability. You can show regulators exactly how vulnerabilities are managed, who is responsible for them, what's been fixed, what's been kind of processed, and have all the evidence ready to go from one single reporting platform.
Why is having a centralized SBOM and vulnerability platform now critical—not just “nice to have”?
So having a centralized SBOM and vulnerability platform now is critical because expectations have changed.
Regulators, compliance bodies, partners, and customers all want transparency. They want a centralized platform that they can get trust from without expecting extra manual work to get the answers of what they're looking for.
What’s one piece of advice you give customers trying to mature their product security programs?
One bit of advice I think I'd give for anybody wishing to advance their maturity program is to define ownership early. Know who's responsible for what, build any form of automation around workflows that you can, and remember that clarity drives progress.


