[markcurphey]

I was actually involved in a load of Log4J responses. I was the founder of sourceclear, the first SCA security pure play. I do get your point but what I see time and time again are things like a repo being built to say a war file and no one knowing where that file was deployed. We just finished a set of fresh interviews with over 50 security leaders and they almost all spoke about that issue, they don't know where things are despite using Snyk and other tools because there is no linkage in their environment between the repo and the deployment. I get your analogy nut I think its more like saying there is no point in a fancy dashboard on a car if the telemetry coming off the engine is questionable.

[richbell]

I looked you up after posting that, so I am willing to eat crow. ;)

While I understand and agree with the larger thesis of your article, I feel like it sends the wrong message. I work at a large FI where it's common for applications to be developed by a vendor and then dumped into the environment as a massive .war file — the White House's push for SBOMs gave us significant ammunition to drive changes around in-house and vendor built apps. Is scanning all of this stuff with a SCA tool like Snyk, Xray, or Nexus Lifecycle going to give you 100% coverage and help you realize that an intern installed a vulnerable version of Elasticsearch on a VM without telling anyone? No. Are there going to be false negatives where the scans don't report the proper dependencies? Yes. But having an inventory of what you have is a great first step, even if it isn't 100% active or you don't know where it's deployed — as long as you're cognizant of those limitations.

> We just finished a set of fresh interviews with over 50 security leaders and they almost all spoke about that issue, they don't know where things are despite using Snyk and other tools because there is no linkage in their environment between the repo and the deployment.

I was the "war room" and heavily involved with Log4Shell remediation, so I completely agree and empathize with this experience. We were lucky to have a large suite of tools like Tenable, Aqua, Mergebase's open source log4j-detector, and an in-house built catalog of all servers and assets, which allowed us to piece together info and get a better understanding of the environment. We did multiple passes of environments with multiple tools. It was a greulling month of work, but it would have been even more so if we didn't have existing imperfect solutions.

[markcurphey]

Def don't need to eat crow. Never heard that phrase before funny. It's just my opinion. I often get it wrong and there are def a few ways to think about it here.

100% agree on getting more visibility and ammunition and 100% agree on having an inventory. I was leading the effort at the OSSF to create to the plan that was taken to the WH summit ;-)

I can't believe that there isn't a good tool for being able to scan production to match build outputs. Sounds like a good OSS tool project !

[robertlagrant]

I don't quite understand the deployment issue. I mean, I understand people might not be tracking what's deployed, but I don't understand what is missing for it to be happening today, other than will.

For example: I build some software into a Docker image, version tag it, sign it, and generate an SBOM for it. That image goes into production with signature validation. Even if I've included 100 jar files in there, I should know exactly which ones I have. I can upload the SBOM to my DependencyTrack[1] instance to so over time no dependencies have vulnerabilities I'm not aware of.

What doesn't work in that scenario? What scenarios can't conform to that one?

[1] https://dependencytrack.org

[markcurphey]

Certainly 'will' is a huge issue, the biggest IMO. I def on't disagree it can be done but my experience and from interviews recently people just don't know. People don't know where their containers are deployed. They know whats in their registries of course but can't trace it all the way though. What I have also seen is people using deploy optimisation tools that dynamically pull from multiple code repos, containers and orchestrate highly optimised global deploys. I def on't disagree it can be done, just it usually isn't.

[robertlagrant]

Right, that makes sense. In that instance, they need to be enforcing some (internal) standards. E.g. "everything should be deployed on monitored k8s so I can pull deployment info from them and find out what I have deployed".

But then, the issue you're now describing doesn't seem to be anything to do with SBOMs being deficient in any way, or lockfiles being bad. How are you connecting those things?

[markcurphey]

100%. Sounds like a great OWASP project to capture those best practices doesn't it ? Want to volunteer ? ;-)