Four Risky Linux Development Behaviors to Stop Now
By: Sean Blanton
TL;DR: Linux offers developers a huge amount of control, optionality, and flexibility—that’s why it’s so popular. But Linux’s flexibility is a double edged sword, and some of the most common developer behaviors can introduce serious security vulnerabilities.
Linux is one of the most popular frameworks for development today, and with good reason: It’s incredibly flexible. Companies can customize almost anything inside production environments. While that’s a huge benefit for creative control and rolling out products, it can also introduce security risks. Many teams are surprised to learn some of the biggest risks are introduced by everyday commands and activities.
Today, we’re tackling four common developer behaviors that could be introducing risk to your organization’s security. How many of these are your developers doing?
#1: Storing Credentials or Secret Information in GitHub
GitHub rules the dev world. In their latest State of the Octoverse report, the company reported over 44 million new repositories in just one year, more than 40 million users, and 2.9 million organizations globally using GitHub.
But all too often, devs use GitHub to store credentials, secret information (like SSL certificates) and configuration files. Even if these details are stored in a private repository, it’s a security risk. What happens if the information gets accidentally exposed to the public through a change in permissions? Or what if the box gets hacked?
Companies should add layers of defense for sensitive information. One of the best layers involves storing credentials on a separate server, requiring your service to ask another server for permission to access the data. This creates a record of who accessed what, when, and where — vital information to investigate a suspected intrusion or to satisfy auditing needs. The rights tools and technologies can also help limit access to different kinds of secret information. For example, user group A can access a specific type of data, but users outside that group cannot.
Helpful Resources and Solutions:
Whether you’re a big company or a little startup, double-checking secret information practices is a good idea. Some useful tools for solving the issue of security and secret information are HashiCorp Vault and Google’s Secret Manager.
#2: Not Reviewing Dependencies Before Including Them in Code
Open source is a central component of much modern software. When it comes to creating a new product or feature, it’s easier than ever for devs to find the perfect piece of open source code to solve an issue. There are countless libraries for the taking. But who is doing a quality check to make sure the dependencies introduced via that library—or multiple libraries—are solid?
While using open source libraries is a standard development practice, not checking for dependencies before deploying code to production can introduce security risks. For example, a library could have a security vulnerability, or a combination of two separate libraries could create a security vulnerability. Additionally, if there are multiple libraries, it can be difficult to pinpoint security issues.
We’ve seen more and more discussions of dependencies on Hacker News, and there are some famous examples out there already like Node.js, which has examples of injected, malicious code that makes it through to production.
Helpful Resources and Solutions:
Some companies, like Snyk, have solutions that allow companies to identify and correct problems in open source code. That said, this is really a matter of company culture, coding policies, and best practices. Good communication is key, especially between developers, DevOps, and security teams. If your company is using open source libraries, creating guardrails to look for dependencies in code is also important.
#3: Developing in Local Environments
When a developer is tasked with creating a new feature or product, they will turn to their local machine before anything makes it to DevOps or Production. Because it’s local (and thus isolated from the business and larger internet), this often means that security standards are treated differently than corporate or cloud environment policies. For example, keys and passwords may be stored locally on their computer to make testing and development both easier and faster, even though this would never be the case in a Production environment.
This is a similar issue to #1 above—storing sensitive information in unsafe spots—but with a few extra possible vulnerabilities. What if the computer gets hacked, left behind in a coffee shop, or lost in baggage at the airport?
Or, what if this code accidentally makes it into the path to Production? At best, time is wasted having to backtrack, revert code and start all over again. Maybe a slap on the wrist follows. But if that code goes further, passing through checks and QA due to a combination of tight deadlines, competing priorities and simple human error, there could be a huge exposure that could cost the business dearly.
If an unauthorized user gets into critical systems, it can mean big trouble. Organizations need to ensure that all code-creation environments are secure, and any endpoint that has access to key systems is monitored and controlled.
Helpful Resources and Solutions
Setting up secure environments for staging is the solution here, with extra protections for credentials—including two-factor authentication, rotating credentials, secure password vaults, and more. For example, our platform integrates with Duo, Slack, Yubico and other 2FA solutions to add an extra layer of security. We then record all activity within Production environments. Also, consider creating a checklist before a project moves into Production to make sure all credentials are not hard-coded and have the ability to be rotated.
#4: Not Communicating With Operations
Last (but certainly not least) on our list is communication. The current software development lifecycle moves incredibly fast, and Devs are asked to achieve huge feats of coding in very short periods of time. The typical process — ask the Dev team to create something; they create it; it gets handed to Ops; it moves into Production; it gets deployed — requires many hands to complete.
But developers and operations teams often operate in silos, and organizational structures can create a “toss it over the wall” dynamic, where Devs create on local machines and then hand off to Ops completely to take it from there. Since they’re coming in after something has been created, the Ops team will inevitably have lots of tactical questions, such as:
Do you have credentials?
Where do users come from?
Who OK’s the users in this piece of software?
As a result, deadlines start to slip or change, which can be frustrating to developers, operations, and the business managers looking to launch new products and features in a timely way. If Devs and Ops had more communication and collaboration early on, they could discuss security needs, the restrictions of production, and more.
Helpful Resources and Solutions
We’re big fans of a modern DevSecOps approach, with lots of communication and synchronicity across development, operations, and security. When a project lands on someone’s desk, get everyone involved from the start to understand the request and discuss the technical and security needs for staging, pre-prod, production, and beyond.
If these details are clear from day one, the project has a much better chance of staying on track and resulting in a secure product.
Devs are the Heart of Software Development
Developers are at the heart of all software development, and they’re asked to create incredible products on short timelines. At the same time, security issues are on the rise, especially with the increasingly remote workforce of 2020. That’s why tackling some of the basic behaviors that can introduce risk is more important than ever before. Organizations that ensure security at every stage of development will be better positioned to quickly and securely release products for their end users.