What Day Had The Most CVEs Published?

That was the simple question I asked myself on Saturday morning, thinking the answer would likely be simple to find. It wasn’t and ended up 48 hours later with me building this jupyter notebook to find out.

I really thought it would be as easy as pulling down the NVD data feeds and running a simple nvd['Published'].value_counts().head(10) to find out that 1098 of 146450 CVEs were published on 2004-12-31.

I even produced a nice little graph:

Except, looking at it, that data didn’t make much sense. With some more research and help, it became clear the data quality from NVD is pretty poor.

Using a tool called MissingNo to get a visualization makes it obvious that only about half the CVEs in the data are complete:

White Space is Missing Data

When you drop CVEs that are missing the CVSS BaseScore to clean up the data here is what the new graph looks like:

The “best” answer to What Day Had The Most CVEs published appears to be 2020-04-15 with 508 of 72964 CVEs published that date.

Here is what the top 10 days looks like:

2020-04-15    508
2018-07-09    431
2019-12-18    364
2018-06-11    349
2018-02-15    340
2017-08-08    316
2019-09-27    309
2020-03-12    307
2018-04-18    281
2017-04-24    281

All that being said, I am not a Data Scientist so I am open to any pull requests or suggestions on how to improve the data in the notebook I built.

CVE Stuffing

I monitor the @CVENew Twitter feed to keep up with any interesting new vulnerabilities that are released. On December 11th CVE-2020-29589 was published claiming that “the kapacitor Docker images through 1.5.0-alpine contain a blank password for the root user” and that it has a CVSS score of 9.8.

This CVE was just a re-report of CVE-2019-5021, which I researched last year when it came out. AlpineLinux rightfully claims in their write up that “You are not affected unless you have shadow or Linux-pam packages installed.” Checking the DockerFile for the Kapactior image, it has neither package installed, so this container is not affected by either the root CVE-2019-5021 vulnerability or even the new CVE-2020-29589 it was just given. Mistakes happen, so I reached out to InfluxData to ask them to dispute the CVE and moved on with my day.

Then it started to happen. Over the last 7 days, the following CVEs were filed claiming the same issue with no verification or even attempting to reach out to the container owners to let them know a CVE was filed.

The descriptions have even started to worsen as with CVE-2020-35466, which lists the affected product as “Blackfire Docker image – store/blackfire/blackfire“, making it impossible even to check if the vulnerability exists.

With the expansion of CNAs, I know that the overall amount of CVEs will explode, with XSS bugs in specialty software like CVE-2019-14478 becoming more common. However, as long as there is some effort to verify the vulnerability, the data is still useful. If we get to the point where you can not even trust the data in a CVE is accurate, security teams’ ability to mitigate vulnerabilities becomes impossible. As Michael Roytman told me, “The only thing worse than no data is bad data,” and that is what is happening here; the CVE database is being stuffed with bad data. I have not found a way to contact the NVD or Mitre about these CVEs and am only having mixed luck letting the container owners know to dispute the CVEs.

Practitioner To Researcher

I joined Kenna Security two years ago as their Principal Security Engineer not long after my friend JCran joined as the Head of Research.   In the last two years, while building the security team, I have stayed deeply involved with the research team, and from time to time, some of that research was made public:

I always enjoyed being a practitioner and helping secure systems and software hands-on, so I had what I considered a perfect role that allowed me to do that and be as involved in research as time allowed. Then last month, JCran moved on to focus full time on intrigue.io, and it left me with a professional quandary of what my next move should. 

I have always loved security research, and after initially being hesitant to move away from a practitioner role into a full-time research role, after a few discussions with Ed Bellis, it became clear that the position would be an excellent fit for my skills and a fantastic career opportunity. 

With all that being said, I am happy to announce I am starting my transition to Director of Research at Kenna Security over the next few weeks.   

What does that mean logistically?  It means I will be 100% focused on bringing actionable data to Kenna’s customers with an admittedly blue team slant to help improve an already industry-leading product.  I will also be spending a lot more time writing and releasing open source security tools and blogs. One of the most important new aspects will be talking to practitioners to understand where their vulnerability management systems are failing them and what would make their lives easier.  You should expect a lot more content here, on my GitHub profile, and on KennaResearch.com as I get started. 

Build An Open Source AppSec Pipeline Using Github Actions

Github Actions was launched last November and it has taken a little while to mature but it has recently got to the point where you can build a fairly robust application security pipeline using Github actions.

In most of my projects, I can run a Linter, an SCA, a SAST and DAST tool aginst my code daily using open source software I have used for years. In this blog post, I will lay out the actions I am using and that are worth exploring.

Github Actions Basics

Here are just some essential links and blog posts I have used over the last few months that I have found useful.


A linter is a tool that analyzes source code and flags errors, bugs, stylistic issues, and suspicious constructs. Often these are run inside of an IDE but it never hurts to have a centralized linter, especially when multiple people are contributing to a repository.

Github has the best linter I have come across called SUPER-LITNER which I use on all my repositories.


Software Composition Analysis (SCA) tools attempt to detect publicly disclosed vulnerabilities contained within a project’s dependencies. The tool you use will depend on what language you write in but Bundler-Audit and many other tools are available in the Github Actions Marketplace.


Static application security testing (SAST) are tools like a linter that check source code for possible vulnerabilities and weaknesses. One again which SAST tool you use will depend on what language you right in but since I mostly write in ruby or python I use Brakeman and PyCharm.

There is a new SAST called App-Threat which is trying to be the Super-Linter of SAST That might be worth looking at.


Dynamic application security testing (DAST) are tools that scan a live website for vulnerabilities and while running these from a GitHub action seems counter-intuitive the fact the OWASP ZAP makes this so easy it is worth doing daily just as a sanity check against your other DAST scanners.

Here is a good blog post on ZAP Actions and here are the baseline and full scan.


Are there any Github Actions I should using? Let me know on twitter at @jgamblin.

Exploring OSQuery With Jupyter

I have been spending a lot of time over the last few weeks looking at the OSQuery to get a better understanding of what it can do since it seems every major security tool from Sophos to Cisco to CarbonBlack is building it into their product.

I have also been looking at Juypter notebooks for machine learning and data science work recently and decided to build a notebook to help explain and show the power of OSquery on MacOS.

This notebook is here and is a WIP that I hope to expand over the next few weeks. Right now it runs 12 queries and displays the data in a data frame.

Here is an example of the displaying logged in users:

Here is the OS Version:

Quick Notes

  • This is built for macOS
    • I will try to build for Windows, RHEL, and Ubuntu soon.
  • You can run the query found in commands = [] directly on the command line and get JSON back.
  • If you have any questions please reach out to me on twitter @jgamblin.

Zoom Video Backgrounds From Youtube Videos

Did you know you can easily turn any video from Youtube into a background for Zoom (Version 4.6.4+) using a simple command-line tool called Youtube-DL. One of my favorite videos is The Traveling Bird Feeder so I will use it for this example.

  • Install Youtube-dl:
    • brew install youtube-dl 
  • Then fingerprint the video:
    • youtube-dl -F https://www.youtube.com/watch?v=vu72ja_mGME
  • Then download any video larger than 640×360:
    • youtube-dl -f 18 https://www.youtube.com/watch?v=GsN_9a257rM
  • Go to Zoom preferences and add the video you just downloaded and amuse your coworkers:

On-Demand Container Scanning API

Last summer I launched vulnerablecontainers.org to help shed light on the number of vulnerabilities in the 1,000 most popular containers on docker hub.  While it was an interesting project, right after I launched the project I had multiple people ask if it was able to scan other public containers. Initially, it wasn’t but I wanted to offer the ability, so over the last two weeks, I decided to not sleep and built my first API that I am publicly releasing today.  

scan.vulnerablecontainers.org is an open python API built using TrivyFlask, Gunicorn, and Nginx that for now has two public endpoints (more endpoints and tools coming). From the start, I designed it to be easy to use in the browser or on the command line for integration with CI/CD.

Trivy Scan Report

The most useful endpoint provides a trivy report of all opened vulnerabilities for the container and is available at: 

Usage Example:

Example Output:

CVE List

This endpoint provides a list of open CVEs on the container and is available at:

Usage Example:

Example Output:

Advanced Usage:

Closing Notes:

  • This is a work in process and is in EARLY beta.  Please do not build this into production systems.
  • The API will only work on containers built using Alpine, RHEL, CentOS, Oracle Linux, SUSE, Amazon Linux, Debian, Ubuntu, and Photon OS.
  • I have attempted to implement some caching but it may take up to 120 seconds to return results.
  • I will release source code, a docker container, and a build guide after some more testing and hopefully adding more endpoints.
  • Notice Something Boken? Please Let Me Know on twitter @JGamblin

What To See At RSA 2020

With the RSA Conference less than a week away I figured I would spend a few minutes and write a quick post about what I am excited to see this year in San Francisco.

Not At RSA

Like most security conferences these days while the conference itself is the reason I go the auxiliary events end up providing a majority of the value and information I take away.

Here is what I am looking forward to seeing not at RSA.


RSA has a reputation for being an “industry” event and while that isn’t totally untrue you can find great content if you look.

Fun Stuff:

Xaxxon OpenLidar Install

One of my personal projects this year is to understand and build a SLAM (Simultaneous localization and mapping) robot. To get started I bought the Xaxxon OpenLidar and after a few struggles getting it to work correctly in a VM I finally did and decided to throw together my build notes for future reference.

Virtual Platform

While I would have liked to use (and tested) Virtualbox there is a known issue with RVIZ that isn’t present in VMWare Fusion, so while I hate not keeping this open-source I could not get it to work.

Ubuntu Install

You want to start with a new Ubuntu18.04 Install (ROS isn’t Ubuntu 19.0 compatible yet with the VM tools installed.

Run these commands to update and install the need utilities:

sudo apt update -y
sudo apt upgrade -y
sudo apt install git curl screen

ROS Install

ROS is the Robot Operating System (ROS) is a set of software libraries and tools that helps you build robot applications. You need it installed to run the OpenLidar hardware.

Here are the commands to install it:

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'
sudo apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654
sudo apt-get update
sudo apt install ros-melodic-desktop-full -y
sudo rosdep init
rosdep update
echo "source /opt/ros/melodic/setup.bash" >> ~/.bashrc
source ~/.bashrc
sudo apt install python-rosinstall python-rosinstall-generator python-wstool build-essential mesa-utils

OpenLidar Install

The last step is to install the software for the OpenLidar system and configure all of the variables and reboot.

Here are those commands:

mkdir -p ~/catkin_ws/src
cd ~/catkin_ws/src
git clone https://github.com/xaxxontech/xaxxon_openlidar.git .
cd ~/catkin_ws/src
cd ~/catkin_ws/
echo "source $HOME/catkin_ws/devel/setup.bash" >> ~/.bashrc
source ~/.bashrc
sudo adduser $USER dialout
sudo reboot now


Once your VM reboots and you connect the Uart Bridge to the VM and you are now ready to fire up the software. That can be done with these commands:

roslaunch xaxxon_openlidar xaxxon_openlidar.launch &
roscd xaxxon_openlidar
./rvizlidar &

You should then see the RVIZ window load and data start populating the screen like this:


If you run into any problem you can always serial into the Lidar and check it with some of the commands on this page.

screen /dev/ttyusb0 115200
Unnecessary gif of the OpenLidar Spinning

The Ten Security Stories That Shaped The Decade

As the 2010s come to an end I started to think about what security stories from the last ten years changed how we think about security in this decade and the next. While this list is in no way complete these are the ten stories that I think had a lasting impact on security in the last decade and the next.

Stuxnet – 2010

Stuxnet targeted SCADA systems and was responsible for causing substantial damage to Iran’s nuclear program. It has been the subject of many books and even a movie.

It has been publically confirmed that Stuxnet was created and built by the NSA in partnership with the CIA and Israeli intelligence.

LulzSec – 2011

LulzSec was a high profile hacktivist group that hacked Sony Pictures, HBGary, and PBS along with many other organizations. Its history and reputation are complicated with many of its members’ serving prison sentences and others have become members of the security research community.

Heartbleed – 2014

Heartbleed was an improper input validation bug in the OpenSSL library that allowed a malformed heartbeat request with a small payload and large length field to permit attackers to read up to 64 kilobytes of the victim’s memory that was likely to have been used previously by OpenSSL.

One of the humorous takeaways from this bug is that it was submitted at 11:59 on New Years’ Eve 2011.

Probably the most lasting takeaway is after this vulnerability Google established Project Zero.

The Shadow Brokers – 2016

The Shadow Brokers were a hacker group that published several leaks containing hacking tools from the National Security Agency including several Microsoft zero-day exploits that lead directly to WannaCry.

It is widely believed that Russia was responsible for these leaks although how they obtained the information is still unknown.

WannaCry – 2017

The WannaCry ransomware attack targeted computers running the Microsoft Windows operating system by encrypting data and demanding ransom payments in the Bitcoin. It propagated through EternalBlue, an exploit developed by the National Security Agency and stolen and leaked by The Shadow Brokers a few months prior to the attack.

Marcus Hutchins discovered the kill switch domain hardcoded in the malware and registered the domain which limited the spread of the ransomware.

Sony Pictures Hack – 2014

In 2014 sony pictures were hacked and personal information about Sony Pictures employees and their families, e-mails between employees, information about executive salaries at the company, and copies of Sony films were stolen and released on the internet. The attackers then released a disk wiper bot that formated a large number of hard drives at Sony.

It is widely believed that North Korea was behind this attack because Sony had made the movie The Interview which plot revolved around trying to assassinate Kim Jong-un.

US law enforcement agencies have charged Park Jin Hyok with this attack and for masterminding WannaCry.

DNC Hack – 2016

Russia hacked and released DNC internal communications to WikiLeaks in the run-up to the 2016 presidential election. While the technical details of these attacks are not impressive, America and the rest of the world have been dealing with the fallout from these breaches and will continue to do so for the foreseeable future.

Chelsea Manning – 2010

In 2010, Chelsea Manning gave WikiLeaks 500,000 documents that became known as the Iraq War and Afghan War logs along with numerous Diplomatic cables. She was arrested in May of 2010 but the information she had given to Wikileaks which made them a household name and allowed them to play a role in the DNC Hack and releasing the information that Edward Snowden leaked.

OPM – 2015

 In 2015, the United States Office of Personnel Management (OPM) had a data breach that affected approximately 21.5 million people. These included an unknown number of SF-86 (Questionnaire for National Security Positions) forms and over 5 million fingerprints.

Most experts have blamed China for this breach but no public proof of this has been shared.

Equifax – 2017

This was a huge data breach that ended up exposing the data of roughly 200 million consumers using a vulnerability in the Apache Struts framework. The House Oversight Committee has released a full report on the breach. Many security experts see this attack as an eyeopener for companies to look closely at their internally developed software along with their OS and Network patching.

No one has taken responsibility for this attack and none of the stolen data has ever been reported to have been used.


Six of these stories come directly from State actors attacking either another country or a large corporation, one of them was an insider threat, one was a determined group of motivated external attackers and one was a really nasty bug a developer submitted at 11:59 on New Year’s Eve and Park Jin Hyok is probably the most dangerous hacker in the world.

Did I miss a story that should have been on this list? Let me know on Twitter at @JGamblin.

Site Footer