This may be a bit oversimplified, but a search of metacpan for UUID returns 355 results. If I was maintaining code against a module upstream that seemed unresponsive to security threats, I'd consider a PR to that module and, failing that, a PR to the code using it to retarget against another module.

One thing to remember with any of these systems is not to either stay stuck on old versions past their usefulness nor blindly update to the latest versions without looking. People get into the habit of not updating, which keeps you from getting fixes. Other people get in the habit of updating in automation without reviewing the changes, which allows supply chain attacks. If you're using a CVE-tracking system like Mitre, they'll tend to tell you in which versions a vulnerability was fixed. The module's changelog should mention the CVE and that it was addressed, too.

If you do want to do your own security review of every piece of code you use, more power to you. I wish you the best. Yet most developers are not security experts and many security experts are not software developers. There are certain overlapping skills one needs to do a thorough and reliable security review of code. Checking against a single known vulnerability disclosure is a bit easier, but not everyone is ready to do that. I would suggest most developers trust the disclosure/correction/reported correction cycle of systems like the CVE reporting sites, complete with CVSS. If you can show a known vulnerability and can show it hasn't been addressed, move on to different dependencies if you can.

In some cases it's possible to look at the CVSS breakdown, look at how your code is used, inspect how your code uses the dependency, and determine a way to acceptably mitigate risks in unpatched dependencies. That, again, is neither purely development nor purely security knowledge.

Your core concern appears to be that developing software which faces an unknown public is not easy to do securely. To that, I can only say that you're absolutely correct. It is not a simple process to assemble multiple pieces from multiple internal and external parties, do some integration around them, deploy them to public-facing systems, and have a reasonably secure system. There are ways to make it easier, but not to make it easy. Many of the ways to make it easier do not make it less expensive. Such is life.

In reply to Re: Libraries and security by mr_mischief
in thread Libraries and security by davies

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.