CVEs are Common Vulnerabilities and Exposures. They are entries in a database that identify security vulnerabilities in software or hardware products. CVEs are assigned by a central organization, called the CVE Numbering Authority (CNA).

A CVE entry contains a description of the vulnerability and a reference to the source of information about the vulnerability. CVE entries are used by security researchers, vulnerability management tools, and operating system vendors to learn about and track security vulnerabilities.

Operating system vendors use CVEs to help their users patch vulnerabilities. For example, when a new CVE is announced, the vendor can check if any of their products are affected and then release a patch.

What is most important to know about CVE’s?

I’m talking to the young DevOps, shift left automation folks here. I don’t think any of this is going to be new if you’re an old sysadmin and have ever dreaded the next Patch Tuesday. I’m not sure contemporary DevSecOps strategies really handle the duality of exploitation. We’ll end up with more than 20,000 CVEs by 2021, and perhaps 150 of them will ever be exploited. Those are the ones that matter most to everyone else, and for many people, they’re the only ones that do. So this one goes out to the young DevOps, shift-left automation folk. I don’t think any of this is going to be new if you are an OG sysadmin and ever waited with dread for the next Patch Tuesday.

I’m not sure if today’s DevSecOps standards address the duality of attack. We’ll have more than 20,000 CVEs by 2021 and maybe fewer than 150 of them will ever be exploited, according to current trends. Those are the ones that count for everyone and for many of us, they’re all that matters.

If you fix all of your problems in a month, fantastic job! Because those who will be exploited will have been so by then. Your ability to patch the few that will be subjected to attack within hours matters more than whether or not you ever fix the remainder if the goal of your patching is not to get hacked.

Let’s look at what you do to get into the top tier. I’m sure it was a close call

• You construct the majority of your things in pipelines, and you run one of the CVE scanners there or use dependable to automatically update your versions with a PR.
• You started doing it and discovered that you already had 800+ CVEs for your service, so you’ll have to wait until the next trainee joins to clean those up. You set the pipeline in place not to break so you could keep working, and you left the notification level on High risk so that you could give it your best shot since you knew there was a lot of stuff that didn’t even have a solution. That, or after obtaining 200 PRs in a week, your enthusiasm for dependable has faded.
• Every other sprint, someone takes a bite out of the bullet to triage everything that comes up and roll the “critical” updates. You also keep vital components up to date every now and then for cleanliness.
• The assumption is that if something were truly important, someone in the team would notice it by reading one of the “You wouldn’t believe which web server created millions of servers vulnerable!” pieces of writing.

So what is this all about?

As a consultant, if you’re doing these things, you’re definitely in the top tier! Unfortunately, this will miss the most important issues since you are attempting to address noise. The return becomes insignificant if you are addressing additional vulnerabilities or if you fall outside of that time frame.

If you know there are only 50 vulnerabilities in a pool of 20,000 that are relevant to you and that you have more hours to address them, it’s evident that asking the question “What vulnerabilities do I have?” is not just a poor method, but also a waste of time.

There are numerous fascinating services, both paid and free, that will tell you all about the flaws you have, offer information that may help you triage them, and even try to determine whether they are exploitable in your situation.

Unfortunately, if you’re searching for information on what’s being attacked, it’s not as simple as it used to be. There are some premium Threat Intelligence services that might supply you with useful information on this subject, but there is no open information available and it isn’t easy to search for when time is of the essence.

We are here to alter this. inthewild.io was designed to gather exploitation and exploit information regarding vulnerabilities, as we think it’s the most critical data for you to manage.

You must first establish the best way to get started.

Hook up our exploitation RSS feed to a Slack channel and triage what comes in there immediately! Is RSS outdated? We have an API and even exported database records. Do whatever you want! You may also just follow us on Twitter.

If you only need to operate with data occasionally, try out our hourly export or the CLI tool in our Docker image that includes a pre-loaded database.

We welcome you to contribute.

For those of you who have some nice TI and discovered or know from an authoritative source that a vulnerability is being utilized in the wild, please let us know so we may inform others.

What’s the purpose of that?

• This is all about the safety of the Internet. If we can build a quick and low-noise signal channel, everyone wins.
• Because it is simple, you will inevitably Tweet or publish on LinkedIn about it, simply include our handle as a tag, and cite your source. If you’re not into social media, there’s also an API.
• Our database will be open source. Every hour, we release exports on a public GitHub repository, and our API is free to use. Even businesses will be encouraged to utilize the data; the easier it is for more people to access it, the better.
• If you tell us that you will be credited as a source