[HN Gopher] The SBOM Frenzy Is Premature
       ___________________________________________________________________
        
       The SBOM Frenzy Is Premature
        
       Author : todsacerdoti
       Score  : 4 points
       Date   : 2022-10-03 19:57 UTC (3 hours ago)
        
 (HTM) web link (blog.crashoverride.com)
 (TXT) w3m dump (blog.crashoverride.com)
        
       | robertlagrant wrote:
       | I disagree with much of this article.
       | 
       | Package managers should be deterministic when using lockfiles.
       | 
       | Manually updating dependencies in a commit and pushing that is a
       | good idea.
       | 
       | Having automation keyed off a release to push an SBOM for that
       | version is not asking much. The scans are extremely fast.
       | 
       | Deployments should be as immutable as possible, if for no other
       | reason than to know you've tested what's being deployed. I'm
       | astonished this article has been written with this conclusion in
       | mind.
       | 
       | Curious as to what others think, though.
        
         | richbell wrote:
         | I also strongly disagree with his take on dependency pinning:
         | 
         | > Solutions to this problem are running SCA combined with
         | automatic updates at every build and hot patching in
         | production. What is not a solution to this is dependency
         | pinning, a technique getting widespread adoption but very
         | dangerous for security in the real world
         | 
         | Not pinning versions is a small benefit -- automatically
         | downloading the latest compatible version of a dependency -- at
         | the risk of enabling a whole new layer of supply chain attacks.
         | I _don 't want_ npm to automatically download a dependency that
         | was published 3 minutes ago and hasn't been vetted or tested by
         | anyone.
        
         | richbell wrote:
         | I heavily disagree with this article as well. The author comes
         | across as someone who was not in the war room of any large or
         | security-concious company trying to determine whether they were
         | vulnerable to Log4Shell. _Anything_ is a significant step
         | forward from what we have now, which is nothing.
         | 
         | The fact that package managers aren't deterministic is an even
         | stronger argument _for_ SBOMs, not against.
         | 
         | I suspect the confusion is that they think SBOMs are
         | disconnected from the actual artifacts that get deployed. They
         | shouldn't be. In most circumstances, even if you arent
         | deploying to "the cloud", you should be following basic "12
         | Factor App" practices and building your artifact once. As you
         | mentioned, deploying the same artifact to your production and
         | staging environments not only simplifies deployment, but also
         | makes your SBOM accurate.
         | 
         | There is a whole other discussion about software packaging best
         | practices. Saying "SBOMs are bad because packaging is bad" is
         | like saying airbags are premature because we need to fix the
         | brakes first.
        
       ___________________________________________________________________
       (page generated 2022-10-03 23:02 UTC)