LWN: Comments on "CVE-less vulnerabilities"

CVE-less vulnerabilities

jospoortvliet — Sat, 20 Jul 2019 11:05:22 +0000

On top of that I want to challenge the perverse incentive a bit. Yes, it is there, but Red Hat also wants it’s software to be popular and used a lot, otherwise it had no large user base to draw customers from. So it isn’t a 100% bad incentive - it is ‘complicated’ and I’d argue it kind of balances out.

CVE-less vulnerabilities

nix — Wed, 17 Jul 2019 18:22:43 +0000

Oh, I completely agree (I was in the same boat for fourteen years). But that's being incentivized by *something else*, and money is just something to let you eat while you do the something else. If you had enough money to do the something else, would you want more money for the sake of it? If not, you're not incentivized by money, I'd say. (An amazing number of people *are* incentivized by it: I don't understand what they get out of it, maybe they use it to keep score or something primate-status like that?)

CVE-less vulnerabilities

HelloWorld — Mon, 08 Jul 2019 05:10:07 +0000

If there is no bug in the parser, you're not going to be able to break out of the sandbox by sending bad input, whether or not the sandbox has bugs. OTOH if the parser does have e. g. a code execution vulnerability, then the sandbox may or may not be able to mitigate that, but even if it doesn't, that's probably no worse than running the parser without a sandbox in the first place. So no, this isn't magical thinking at all.

CVE-less vulnerabilities

Wol — Thu, 04 Jul 2019 18:03:04 +0000

Cyberax is okay. I think we have some people here who prize belief over empirical evidence. At least you can argue with people who are persuaded by evidence.

And while "security through obscurity" is a bad thing to *rely* on - as a deliberate *extra* feature on top of other measures it *is* good. Run a parser inside a sandbox on a hardened kernel - the attacker has to first discover the security measure before he can attack it, which gives you extra opportunity to discover *him*.

Cheers,
Wol

CVE-less vulnerabilities

Wol — Thu, 04 Jul 2019 17:59:40 +0000

> > As well as you need fuzzing to test sandboxes. I would say for now fuzzing is the most effective way of finding bugs in programs.

> No. The most effective way is to write software in safe languages. E.g. a sandbox in Rust: https://github.com/firecracker-microvm/firecracker - they had no CVEs so far.

The only guaranteed secure way to write secure software is to prove it correct. Try doing that with C and its undefined behaviours - the end result will be quantum with bugs popping in and out of existence at random. And they do! I'm pretty sure there have been several occasions when an upgrade to GCC has caused bugs in software to pop INTO existence ... (because the compiler exploited a loophole in the definition of the language)

Cheers,
Wol

CVE-less vulnerabilities

Wol — Thu, 04 Jul 2019 17:23:51 +0000

> The automatic assumption here that most free software developers are mostly incentivized by money stands in stark contrast to almost every free software developer I have ever met. As a group we are to a large extent paid enough for free software hacking to be privileged sorts who usually don't need to worry about money,

While I agree with the first half of that (free software developers are not incentivized by money), I'm not sure about the second. There are probably a fair few wannabe free software developers (myself included) who lack the time and opportunity precisely because we are NOT paid enough to indulge ourselves in what we want to do (write free software).

Some people get lucky breaks - I'm not complaining - but some people don't.

Cheers,
Wol

CVE-less vulnerabilities

samuelkarp — Mon, 01 Jul 2019 21:13:26 +0000

> a sandbox in Rust: https://github.com/firecracker-microvm/firecracker - they had no CVEs so far.

Hey, thanks for the shout-out! This is somewhat of a sidebar, but hopefully I can help a bit. While Firecracker is used in production at AWS, it's a relatively young project. We've certainly tried to build Firecracker in a secure way (Rust is one part of that, a very limited device model is another part, and limiting privileges by default with seccomp and jailing is another), but the short amount of time it has been open-source means the security community hasn't had a lot of time to necessarily identify any issues in it. I think this may be a much stronger argument in the future as the project continues to mature and (hopefully!) security-minded folks have an opportunity to look deeper.

(disclosure: I work for AWS and work with the Firecracker team; I am helping to build firecracker-containerd, a project focused on managing container workloads inside Firecracker microVMs.)

The CII Best Practices badge does require dependency monitoring (at the silver level)

david.a.wheeler — Mon, 01 Jul 2019 18:39:15 +0000

The "passing" badge doesn't require it, but the "silver" badge (the next level) of the CII Best Practices badge certainly does require that. The dependency_monitoring criterion says:

Projects MUST monitor or periodically check their external dependencies (including convenience copies) to detect known vulnerabilities, and fix exploitable vulnerabilities or verify them as unexploitable. [dependency_monitoring]

Details: This can be done using an origin analyzer / dependency checking tool such as OWASP's Dependency-Check, Sonatype's Nexus Auditor, Black Duck's Protex, Synopsys' Protecode, and Bundler-audit (for Ruby). Some package managers include mechanisms to do this. It is acceptable if the components' vulnerability cannot be exploited, but this analysis is difficult and it is sometimes easier to simply update or fix the part.

There are related criteria to support this, especially external_dependencies, updateable_reused_components, and interfaces_current. In addition, all the test-related criteria in some sense support this, because to rapidly update a component you need to be able to be able rapidly and thoroughly test the result after the update.

In short, the best practices badge does cover this.

CVE-less vulnerabilities

sorokin — Mon, 01 Jul 2019 17:35:39 +0000

> illustrating that sandboxing isn't just for untrusted code -- it's also for mostly-trusted code that is likely to handle hostile data (and where you might not totally trust the language sandbox).

I completely agree with that point. In many cases this can be a completely adequate security measure.

Actually my original comment was about testing. Looking back I regret that I even responded to Cyberax who is arguing just for the sake of arguing.

CVE-less vulnerabilities

james — Mon, 01 Jul 2019 09:44:14 +0000

We were talking about sandboxing. Do you know any examples where people rely on python nor nodejs security to run untrusted code? I don't know of any.

Well, this thread started with rra saying:

Personally, I think it's no longer an acceptable security practice to run an image parser on untrusted input outside of a sandbox.

illustrating that sandboxing isn't just for untrusted code -- it's also for mostly-trusted code that is likely to handle hostile data (and where you might not totally trust the language sandbox).

I know it's Perl, but I'd love the ability to run SpamAssassin in a sandbox (without making any complaints at all about either SpamAssassin or Perl security).

CVE-less vulnerabilities

jschrod — Sun, 30 Jun 2019 18:38:27 +0000

> Are you speaking from experience, having used a faster moving distro before?

Yes, we used to run openSUSEs Tumbleweed. It was not worth the hassle.

The problem is actually not newly introduced errors. They are seldom enough, we were always able to handle them. The problem are incompatibilites in software upgrades that break one's files or -- especially bad -- one's workflow.

For us, it's easier to schedule some time in block where one checks such incompatibilities for a new release (e.g., currently for Debian buster), adapts workflows, and tells all co-workers about these changes in a scheduled and timely fashion. The alternative is having to handle such incompatible changes all day as surprises ("Christine called in, she cannot work any more, fix it ASAP") on top of one's normal workload.

Other companies, with more staff, may see this different than we do. (Although our customer's IT departments *are* larger, and they are even more conservative than we are.)

CVE-less vulnerabilities

jschrod — Sun, 30 Jun 2019 18:29:38 +0000

The problem was not in Debian's kernel update, as I suspected. Otherwise, more of those error stories would have been found. It was an incompatibility between my (quite old) smb.conf and that new kernel.

Actually, I don't know if Debian would have reacted to a bug report about that. I wouldn't have opened one without being sure that there is no problem in my installation or my configuration -- and it was in the latter.

CVE-less vulnerabilities

jschrod — Sun, 30 Jun 2019 18:26:31 +0000

> But someone running a handful of Samba servers, which sounds like jschrod's case, doesn't have those things.

Yes, this is our case -- but even though we're a small company, we still do deployments of updates for important packages on canary systems first. They are used by some admins who know how to handle errors and roll back to a working system. (Canary deployments are done on VMs with snapshot/rollback capability.)

CVE-less vulnerabilities

jschrod — Sun, 30 Jun 2019 18:23:15 +0000

> Running the latest at least as a smokescreen would allow you to catch it at the rc > level rather than after it has been backported.

We caught it when we deployed the new kernel on a canary system.

For our environment (we are a small company) it isn't really needed to learn about such problems earlier. Such problems typically are sorted out within the week and don't disturb production -- here with the help of fellow lwn.net read mdg, even earlier. Usually, we can live with updating our production systems a few days later.

Samba and kernel 4.9.0-9

jschrod — Sun, 30 Jun 2019 18:16:43 +0000

Thanks a lot for this info, that solved it.

Actually, the culprit seems to be SO_RCVBUF and SO_SNDBUF, testparm meanwhile warns about them. (Maybe I should establish a monitoring plugin that runs testparms and checks for warnings...) TCP_NODELAY is actually even default.

This shows again how great the lwn.net community is!!

Thanks, Joachim

CVE-less vulnerabilities

Cyberax — Sun, 30 Jun 2019 17:48:15 +0000

> We were talking about sandboxing. Do you know any examples where people rely on python nor nodejs security to run untrusted code? I don't know of any.
You mentioned managed languages first. So stop moving goalposts.

> I can not comment about Chrome though.
The sandboxed code is single-threaded.

You also seem to not understand the whole concept of sandboxes. Sandboxes limit the operations that the contained code can do, whether it's multithreaded or not. And it's not like regular uncontained libraries can't access threads by themselves, either directly or through injected exploit code.

> As well as you need fuzzing to test sandboxes. I would say for now fuzzing is the most effective way of finding bugs in programs.
No. The most effective way is to write software in safe languages. E.g. a sandbox in Rust: https://github.com/firecracker-microvm/firecracker - they had no CVEs so far.

The second most powerful way is to contain code in sandboxes.

CVE-less vulnerabilities

nix — Sun, 30 Jun 2019 10:24:39 +0000

> You could even be trying to make my point for me: "As parsers are a lot simpler than sandboxes, a lot of bugs in them are eventually found and fixed, as evidenced by the very long list of CVEs relating to such bugs".

You're suggesting that finding more bugs in some piece of software is evidence that it has fewer bugs than other software in which fewer bugs were found in the first place, and you don't think this might perhaps be motivated reasoning so contorted that you could probably find singularities in it?

Thousands of image and other media parser bugs have been found (and continue to be found), even discounting the endless flood from Wireshark's network protocol dissectors. How many bugs have been found in Chrome's sandbox, which has annual events in which people basically get paid for finding holes in it? Is it as many as a dozen?

CVE-less vulnerabilities

sorokin — Sun, 30 Jun 2019 10:17:13 +0000

> No. Quite a few sandboxes prohibit launching new threads, including the one used in Chrome, for example. Managed VMs can also be single-threaded just fine - see Python or Nodejs.

We were talking about sandboxing. Do you know any examples where people rely on python nor nodejs security to run untrusted code? I don't know of any.

I can not comment about Chrome though. I know that it is multithreaded, but perhaps its sandbox runs single-threaded code. I don't know. Ok perhaps this is a example of single-threaded sandboxed environment, still it is an exception. And overtime we will see fewer and fewer single-threaded programs.

> Enough to avoid security bugs. The only effective way to de-louse the C programs is fuzz testing, everything else simply doesn't work. And fuzzying can't find everything.

As well as you need fuzzing to test sandboxes. I would say for now fuzzing is the most effective way of finding bugs in programs.

CVE-less vulnerabilities

nix — Sun, 30 Jun 2019 10:16:16 +0000

Don't underestimate the amount of state that is only present in your mind as well...

If that gets wiped on a desktop reboot you need to get looked at fast. :) going to sleep, on the other hand...

(It's actually almost inverted: going to sleep is helpful even though it results in loss of state: the state that is lost is mostly useless and the improvements gained in knowledge and clarity of thought and just not being tired any more and so on are much greater than the loss.)

CVE-less vulnerabilities

nix — Sun, 30 Jun 2019 10:13:54 +0000

Would you be confident running a 3 months old browser? Looking at the history of Firefox ESR it has seen almost as many upgrades as the stable series. You're upgrading anyways, why keep the old version? Because it has less features and gets less attention from developers?

Well, perhaps the thing you're upgrading is a foundational element in the software stack (a browser might count as that: so might Qt, or the X server, or glibc, or etc etc) and you want bugfixes but a lot of things depend on this and you don't know exactly what things they might be doing, so you'd rather add new features and cleanups and the corresponding code churn, because better tooling or no better tooling, every time the code changes there is the possibility of new bugs. The old code has old bugs, sure, but you already know that those old bugs don't affect your workflow or you'd be upgrading more aggressively because the old software didn't work right for you (with the exception of security problems, of course, where the bugs will be exercised by an attacker, not by you).

So there really is an extra cost to upgrading to new-feature branches versus stable branches. (The downside is the the changes on the stable branch have probably been much less tested on that branch than they were in the new-feature branch they were likely developed against. Tradeoffs, tradeoffs...)

CVE-less vulnerabilities

nix — Sun, 30 Jun 2019 10:08:26 +0000

The automatic assumption here that most free software developers are mostly incentivized by money stands in stark contrast to almost every free software developer I have ever met. As a group we are to a large extent paid enough for free software hacking to be privileged sorts who usually don't need to worry about money, and freed from that tether most of us are interested in other things now (doing interesting things, writing code people will find useful, or just enjoying creating the software system itself).

Certainly, in my case, even a really blatant financial incentive like telling me that you'd double my salary if I did $thing (where $thing is not something I'd have been happy to do already) would not have much effect, and the financial incentive there is pointless: you could probably get me to prioritize a $thing I'd be happy to do over other things I was planning just by asking me, acting as a prod that at least one person has an expressed preference so I might as well follow it.

I suspect that if you *are* mostly incentivized by money, you've long since switched to become a VC vampire rather than a free software developer: God knows you'd have had enough opportunity to do so.

CVE-less vulnerabilities

Cyberax — Sun, 30 Jun 2019 07:51:21 +0000

> OS kernel<->userspace boundary is multithreaded. x86 VMs are multithreaded. Managed languages VMs are multithreaded.
No. Quite a few sandboxes prohibit launching new threads, including the one used in Chrome, for example. Managed VMs can also be single-threaded just fine - see Python or Nodejs.

> Enough for what? I'm telling that one type of programs is easy to write tests for and one is not.
Enough to avoid security bugs. The only effective way to de-louse the C programs is fuzz testing, everything else simply doesn't work. And fuzzying can't find everything.

CVE-less vulnerabilities

sorokin — Sun, 30 Jun 2019 07:47:43 +0000

> Not really. Most of sandboxing environments are thread-agnostic or single-threaded. Unless you're looking at full VMs.

OS kernel<->userspace boundary is multithreaded. x86 VMs are multithreaded. Managed languages VMs are multithreaded.

> As history has shown, this is not enough.

Enough for what? I'm telling that one type of programs is easy to write tests for and one is not.

CVE-less vulnerabilities

Cyberax — Sat, 29 Jun 2019 18:39:43 +0000

> 1. Most parsers are single-threaded while most sandboxing environments have to deal with some forms of concurrency. Which means they are difficult to test.
Not really. Most of sandboxing environments are thread-agnostic or single-threaded. Unless you're looking at full VMs.

> 2. In addition it is very easy to write tests for parsers, because normally they behave like pure functions: they have some input and they produce some output.
As history has shown, this is not enough.

CVE-less vulnerabilities

sorokin — Sat, 29 Jun 2019 17:55:24 +0000

This were exactly my thoughts, but I couldn't find a better words to express them. Thank you!

I would like to add two more points:
1. Most parsers are single-threaded while most sandboxing environments have to deal with some forms of concurrency. Which means they are difficult to test.
2. In addition it is very easy to write tests for parsers, because normally they behave like pure functions: they have some input and they produce some output.

Samba and kernel 4.9.0-9

mbg — Sat, 29 Jun 2019 05:58:10 +0000

jschrod, you're not alone -- I think I hit the same thing.

Removing these options (long deprecated apparently) from my smb.conf seemed to fix it:

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

CVE-less vulnerabilities

Cyberax — Fri, 28 Jun 2019 22:39:32 +0000

The situation right now is this. If you have a C-based parser then it contains remote holes, end of story. Old C-based parsers just have the most obvious holes discovered (usualy).

Just look at libpng, libgzip, libjpeg, Apache, libcurl, ... for examples. Every one of them had multiple severe vulnerabilities in parsing.

So if you are using a C-based parser for untrusted data (which in this world means "all data") then you have at least one security hole.

Sandboxes are a way to mitigate this. They still can have bugs but there is just a handful of sandboxes, and some of them are written in languages that preclude most of regular C bugs.

Of course, if you want to be in the perfect world then you should turn off all computers tomorrow and start a Manhatattan-project style mass rewrite of C software in saner languages.

CVE-less vulnerabilities

rweikusat2 — Fri, 28 Jun 2019 21:11:15 +0000

You "clearly" haven't yet managed to move past the shtick of supplanting assertions of insanity for arguments. Parsing your second sentence yields "I [ie, you] don't know if there were more critical errors in [somehow defined] parsers than in order kinds of software". Even assuming the "but it may well be the case" (aka "probably") as given, one can only wonder what this is now supposed to express. You could even be trying to make my point for me: "As parsers are a lot simpler than sandboxes, a lot of bugs in them are eventually found and fixed, as evidenced by the very long list of CVEs relating to such bugs".

But that's really entirely besides the point. The base situation is still "it is unknown if $parser has security issues, hence it probably has" vs "it's unkown if $sandbox has security issues, hence, it's probably safe to use". These are still two appeals to ignorance used to justify both a statement "A" and the inverse statement "not A".

NB: I do not claim that the parser must be safe or that the sandbox must be unsafe, only that absolutely nothing can be validly concluded from ignorance.

CVE-less vulnerabilities

Cyberax — Fri, 28 Jun 2019 20:25:06 +0000

> There is no way to 'understand' this 'perspective' as it's plainly self-contradictory: Compared to sandboxes, all of which have a history of security issues(!), most parsers are fairly simple.
You clearly live in a separate parallel reality. The never-ending list of critical CVEs in parsers is probably the longest list of vulnerabilities.

CVE-less vulnerabilities

rahulsundaram — Fri, 28 Jun 2019 18:10:39 +0000

> That's now an appeal to popularity, another logical fallacy.

How is empirical evidence an appeal to popularity? Just look at vulnerabilities in parsers vs sandboxes that protect them. It isn't that hard. If you are going to have the outlier position that goes against that evidence, make your case.

CVE-less vulnerabilities

excors — Fri, 28 Jun 2019 18:02:02 +0000

> We don't know if the 'parser' has security issues, hence, it probably has.

When we know the parser has had several hundred security issues in the past (see https://www.cvedetails.com/vulnerability-list/vendor_id-1... , most of which say "...via a crafted file"), we can be pretty sure it's going to have a lot more.

> We don't know if the sandboxing software has security issues, hence, it probably doesn't.

The sandbox doesn't need to be perfect. To exploit a sandboxed parser, you need to find a bug in the parser *and* a bug in the sandbox. That's strictly harder than finding a bug in the parser, so the sandbox makes the system more secure. It's like the most obvious example of defense in depth.

CVE-less vulnerabilities

rweikusat2 — Fri, 28 Jun 2019 18:00:27 +0000

That's now an appeal to popularity, another logical fallacy.

CVE-less vulnerabilities

nilsmeyer — Fri, 28 Jun 2019 17:53:29 +0000

pure conjecture.

CVE-less vulnerabilities

rahulsundaram — Fri, 28 Jun 2019 17:52:02 +0000

> There is no way to 'understand' this 'perspective'

Of course there is but in this case, you have already made up your mind and that's fine. I will just point out that in general, the industry trend is moving towards more sandboxes, not less based on empirical evidence that it is useful. You are just the outlier here.

CVE-less vulnerabilities

mathstuf — Fri, 28 Jun 2019 17:51:09 +0000

> We don't know if the 'parser' has security issues, hence, it probably has. We don't know if the sandboxing software has security issues, hence, it probably doesn't.

You're missing that the parser was written to "get a job done" which is to make a set of pixels from encoded data. The sandboxing software was written to get a job done as well: limit what can be done within an environment meant to run untrusted code. The mindset and review rigor difference between the two should be readily apparent in that I'd expect the latter to actually have a security model and documentation on how it handles that model. The former rarely has one until it has systemic problems.

CVE-less vulnerabilities

rweikusat2 — Fri, 28 Jun 2019 17:34:02 +0000

There is no way to 'understand' this 'perspective' as it's plainly self-contradictory: Compared to sandboxes, all of which have a history of security issues(!), most parsers are fairly simple. The people argueing for this just chose to believe that the 'parser' must have unknown, security-criticial bugs and chose to believe that the sandboxing software will not. This is really just a dual appeal-to-ignorance: We don't know if the 'parser' has security issues, hence, it probably has. We don't know if the sandboxing software has security issues, hence, it probably doesn't.

One should really call this a higher-order logical fallacy as it uses the exact, same falllacious reasoning to justify two contradicting conclusions.

CVE-less vulnerabilities

rahulsundaram — Fri, 28 Jun 2019 15:56:31 +0000

>we must use significantly more complex software B which is believed to be free of unknown bugs because of ... well just because ...

That is a not an earnest attempt at understanding a different perspective. All software including sandboxes can have bugs. However it is easier to specify access points and fix any bugs once in the sandbox that is specifically designed with security in mind compared to parsers which often have a long legacy and history of security vulnerabilities. We do have sufficient experience with sandboxes (for ex: Chrome sandbox or bubblewrap) to know both a) sandbox are not a magic solution 2) they do help to stop or mitigate vulnerabilities.

CVE-less vulnerabilities

rweikusat2 — Fri, 28 Jun 2019 15:07:56 +0000

> Personally, I think it's no longer an acceptable security practice to run an image parser on untrusted input outside of a sandbox. We > should keep fixing bugs in the parsers as a first line of defense, but that line of defense clearly fails frequently enough that one
> needs a second line of defense (a seccomp sandbox, a dedicated container, something). That's probably true of most parsers that
> are even mildly complex.

This kind of magic thinking keeps amazing me: In order to guard against unknown bugs in 'complex' software A, we must use significantly more complex software B which is believed to be free of unknown bugs because of ... well just because ...

CVE-less vulnerabilities

marcH — Fri, 28 Jun 2019 09:33:22 +0000

No, I don't have any experience myself but the article states:

> projects like OSS-Fuzz are finding lots of bugs in an automated fashion—many of which may be security relevant

https://github.com/google/oss-fuzz seems pretty strong on automation and in my experience Google rarely ever pays engineers to perform repetitive tasks.

So it sounds like OSS-Fuzz finally cracked that nut. That's probably why there's a LWN article about it.

CVE-less vulnerabilities

nim-nim — Fri, 28 Jun 2019 07:59:01 +0000

You write it as if some gremlin had connected to your project deep in the night and had made it use all this other code. The dependencies didn’t add themselves, someone in the project made the decision to use this other code, instead of writing the functionality himself.

This person should have evaluated the costs of keeping this code up to date, instead of forking it and maintaining it all directly. Just like he should have evaluated if the API provided by this other code is convenient, if it’s compatible licensing-wise, if it’s actively maintained in the original project and reasonably future-proof, etc.

Costs of keeping other code up to date balloon if it calls itself lots of other third party code, if its authors do not keep APIs stable and backwards-compatible, do not release (each commit is a new thing to look at), do not use semver, do not write changelogs, do not announce new versions on a mailing list. Sometimes choosing something a bit less featured with fewer keeping up to date problems is a better deal.

Anyway checking up-to-dateness can be done using announce mailing lists, release-monitoring.org, pretty much any language that uses a package manager allows querying for the latest version, everyone is moving to git nowadays so you can write your own git pull and check tags monitoring robot, etc. All the major actors (Google, Microsoft via Github, Gitlab, node…) are starting to keep registries of problematic code, and you can use those too (but, that will make you dependent on them, and pretty soon they'll start scoring projects in ecosystems they control, and force you to do whatever changes they want for free, if everyone relies on their score, and a bad score becomes the kiss of death).

Or, just choose things available in a major Linux distro, adhere to its update cycle, and update whenever it does in its devel branch.

There’s no miracle, anything like static linking, containers, vendoring, private forks, that isolates you from the version bumps of others, puts you in power. With power comes responsibility. The less you depend on the update checks of others, the more you need to perform them yourself.

As a rule, any upstream new version should be checked for security or dataloss fixes. Quite often those are not traced, and you end up updating by default, because it's less work than auditing all the code changes to identify what is needful.

LWN: Comments on "CVE-less vulnerabilities"

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

The CII Best Practices badge *does* require dependency monitoring (at the silver level)

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

Samba and kernel 4.9.0-9

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

Samba and kernel 4.9.0-9

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

CVE-less vulnerabilities

The CII Best Practices badge does require dependency monitoring (at the silver level)