Hi, I did not mean that yocto CVE checker is useless, or that bugs like this should not be fixed. Using it is part of the best practice processes for making secure products with yocto (even if it's currently not documented as such).
But we should also document that the CVE checker makes a LOT of assumptions which are frequently broken in real life. poky tries to work well with CVE checker but many other layers and recipes may not work at all. Few reasons are: * recipe name may not match to a CPE product name in the NVD database, and CVE_PRODUCT may not be set * recipe versions PV may not be compatible with upstream version numbers and hance the version range checks may fail * data in NVD is frequently wrong about the version ranges of CVEs And there are more corner cases. All these fail silently. Now you found a problem with the NVD download scripting which I think needs to be fixed. But even if it works, developers who need to run security checks on real products need to do more than just rely on CVE check output. Cheers, -Mikko On Wed, Oct 12, 2022 at 11:51:28AM +0200, Carlo Piana wrote: > [sent from the wrong account, resent, sorry for the noise] > > ----- Messaggio originale ----- > > Da: "Mikko Rapeli" <[email protected]> > > A: "Marta Rybczynska" <[email protected]> > > Cc: "Alexander Kanavin" <[email protected]>, "Alberto Pianon" > > <[email protected]>, "OE-core" > > <[email protected]>, "marta rybczynska" > > <[email protected]>, "Richard Purdie" > > <[email protected]>, "Carlo Piana" <[email protected]> > > Inviato: Mercoledì, 12 ottobre 2022 10:04:07 > > Oggetto: Re: [OE-core] severe issue in CVE checker > > > Hi, > > > > Can the downloads be turned into normal do_fetch() SRC_URI downloads > > including > > caches in yocto infrastructure? > > > > There are many issues around CVE checking that it's really > > a process where a lot of details and uncertainties just need to be > > accepted. It's far from a perfect and users just need to accept this. > > > > > > [...] > > I beg to (strongly, if I may) differ. > > CVE is broken? This is no excuse of course to ignore a known insecurity. > > Is it better to include a process that, when fails, the fail goes unnoticed, > than nothing? No, "nothing" is better than flawed here, speaking of security, > since a false sense of security is worse than insecurity itself. > > If we put a CVE checker that just throws in a contradictory message (a > warning and eventually a "success" one) and then silently moves on without > any fuss, we leave users in a state of false belief that they have completed > at least the CVE checks -- however insufficient this may be -- but in reality > it's a test that never fails because the database is empty or outdated. I > agree that for developers CVE checking, compliance, software component > inventory are a PITA, but it's way more a PITA when an attacker exploits an > unpatched known insecurity kept out in the wild, or when a copyright troll > comes after you demanding (many!) millions in damages (I can't disclose who > has received it, but I have seen it in real life), because you failed to > notice that a GPL component went into a mass-distribution device. > > Once the function is advertised, the expected behaviour for a thing of that > importance must be to visibly flag the issue and **stand in the way** until > you acknowledge it, so that the warning cannot be missed. It is up to the > duly informed user to say "Ok, it's nothing, I know it" and shrug the problem > off. Not a decision taken for the user by others and hidden under the carpet. > We have several clients relying on that CVE checking and just by coincidence > we noticed that something did not add up. God only knows how many times did > this happen before. > > One can think it's not their problem, this is open source after all. But > being open source is not total relief from liability. If you create a hole in > the road and cover it with foliage, the fact that you are not paid to pave > the road and you are doing it as a service for the community does not shield > you if a car takes a nose-dive into it. > > I am sorry to intrude in the discussion so bluntly, but I prefer that the > legal implications are correctly perceived before making a decision. > > All the best, > > Carlo >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171662): https://lists.openembedded.org/g/openembedded-core/message/171662 Mute This Topic: https://lists.openembedded.org/mt/94276393/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
