The popular open source project, 'ip' had its GitHub repository archived, or made "read-only" by its developer as a result of a dubious CVE report filed for his project. Unfortunately, open-source developers have recently been met with an uptick in debatable or outright bogus CVEs filed for their projects.
  • TheButtonJustSpins@infosec.pubEnglish
    30·
    4 months ago

    Recurring incidents like these raise the question, how does one strike a balance?

    Relentlessly reporting theoretical vulnerabilities can leave open-source developers, many of who are volunteers, exhausted from triaging noise.

    On the flip side, would it be ethical if security practitioners, including novices, sat on what they thought was a security flaw—so as not to inconvenience the project maintainers?

    This was already answered in the article: verify your security findings. Make a POC that actually exploits the vulnerability, then submit it with your report.

    • Pika@sh.itjust.worksEnglish
      4·
      4 months ago

      I think a good alternative is a CVE is assigned as somewhere between 1-3 unless proof of concept is able to be assigned, then and only then can the priority to increased to what it should be. these issue reports coming in as a 9 when you basically need to tell the program, “hey I’m being stupid just do it” in order for it to be vulnerable are only wasting developers time. I don’t believe these issues should be ignored however I do think they should be quite a bit lower priority if no concept is provided.