Watching your Back [End], And Your Front [End]: Developing with a Security Mindset
By Sara Cope, Code.gov
In all things in life we want to feel secure. When we get in or out of our cars we lock the doors. We have elaborate security systems in our homes, many with cameras and bells and whistles. You are probably reading this blog from a computer or phone that is password protected. So why wouldn’t we put in place these same safeguards when consuming open source code?
As a developer consuming open source dependencies, you must keep it secure. It is imperative that you set up the tools and processes that will help you stay safe, and help raise awareness of secure development practices throughout your organization.
New Engineer On The Block
I joined the Code.gov team about a year ago to help maintain the front end or “user interface” of our website. I moved over from GSA’s Chief Technology Officer’s (CTO) Digital Service Team. There, I was responsible for a lot of prototyping, wireframing, user interviews, and static site development. At the time there were two other engineers on the Code.gov team — one back end and one front end. When I joined to work on the front end, we naturally began dividing the work with me focusing more on the design/user interface (UI) which I had more experience with. The other front-end developer worked more on the “back of the front” stack including coding JavaScript, components and similar functions.
Things were moving fairly smoothly until we had a shake up within the team. About a month or so after migrating Code.gov from Angular to React, the other two developers left our team. I went from being a part of an engineering team to being the engineering team. This was a very tough transition mentally. I had to figure out a number of topics very quickly — the most important being security.
Security Knowledge is Power
In the beginning, I was not very involved in the maintenance of our application from a security perspective and didn’t really grasp what that entailed. As it turns out, I am not the only one. A recent survey found that 70 percent of open source maintainers stated they didn’t have a strong security knowledge.
You could definitely count me among the 7 percent with low security knowledge and I’d wager this is the case for many front-end folks.
As developers, we have to take ownership in the security of our applications. Whether that is with the code that we’re writing or the code that we’re pulling in from others. You cannot just publish an open source project and then walk away from it. It has to be maintained, especially to check for security vulnerabilities in dependencies. As package counts grow, so do their vulnerabilities. A record setting 16,000 new vulnerabilities were disclosed in 2018.
Scan, Automate, Repeat
A first step to developing stronger security practices is to become more aware of the dependencies you are currently using and more closely vetting the ones you are looking to add to your project.
Use “npm Is” to have a look at your dependency tree and just familiarize yourself with the packages that are there. You can also use a tool like “npm outdated” or a package like “npm-check” to review your project for unused and outdated dependencies. Be sure to take time to review the generated list for false-positives.
Next, get rid of dependencies you don’t need. As the number of dependencies increases, the risk of ending up with a vulnerable package can also increase.
Be sure to add a security audit to your code reviews. You also should consider scanning dependencies at several levels. This can be at the command line, using your source code manager, in the browser, and using continuous integration. Then, add automated continuous monitoring to help relieve some of the dependency maintenance burden.
You should be developing with security in mind just like you do with accessibility scans, performance budgets, and code testing. Security scanning should also be part of your development checklist.
Be mindful that regular scanning isn’t good enough if you aren’t going to apply the changes in a timely manner. A 2017 data breach exposed the personal information of 147 million people because the company went two months without patching a known vulnerability. It is important to move quickly in these cases so that malicious actors aren’t able to take advantage of dependency weaknesses.
Many of us love open source because it is…open. But that doesn’t mean that we don’t have to do our due diligence to keep it safe and secure. For a more in depth look at this issue, take a look at my Open Source Security presentation.
