You’d be hard-pressed to find a day where a cybersecurity incident doesn’t hit the news, whether it’s hackers accessing personal data, undertaking a DDoS attack or deploying ransomware. Over the years, security breaches have crippled industries, damaged businesses, shut people out of critical public and health databases, and caused chaos. You might think your company is protected as you use proprietary software. But it’s not so simple. Open source components and libraries are the foundation of literally every application in every industry, and the need to identify, track, and manage open source software security is more important than ever. Many people will remember what is arguable the worst cyberattack of 2017, upon Equifax, where hackers stole the personal information of 147.7 million Americans from its servers. Hackers used an Apache Struts vulnerability, a months-old issue that Equifax knew about but failed to fix.
Synopsys’ recently launched their 5th Open Source Security and Risk Analysis (OSSRA) report. The CyRC teams examined anonymized audit findings from over 1,250 commercial codebases in 17 industries, including Enterprise Software/SaaS, Energy, and Healthcare. In 9 of 17 industries, 100% of the codebases contained open source.
The authors assert that “Whether you are a member of an IT, development, operations, or security team if you don’t have policies in place for identifying and patching known issues with the open source components you’re using, you’re not doing your job. The open source community usually issues small updates at a much faster pace than the average commercial software vendor. When these updates contain security updates, companies need to have a strategy to adopt them rapidly. But because open source updates need to be “pulled” by users, an alarming number of companies consuming open source components don’t apply the patches they need, opening their business to the risk of attack and applications to potential exploits.”
I recently spoke with Steve Hoffman, VP of Engineering at Percona, who develop open source software projects for MySQL, MariaDB, PostgreSQL, MongoDB and RocksDB users. He notes the visibility of bad decisions: “Some companies can hide behind “security through obscurity”, but open source projects can’t take that approach, so implementations have to be well thought out in advance. We design and code with security at the top of the priority list, otherwise we’ll find ourselves dropping in popularity as we climb the CVE charts.
Open source’s community focus may also be its downfall
Popular open source projects typically are resources with healthy communities of people improving, updating, and patching vulnerability issues as they become known. However, many developers don’t bother to vet the health of a community before downloading an open source component. Even if a developer takes care to initially download components from robust open source communities, there’s no guarantee the community will remain active in maintaining that component or the specific version downloaded.
The OSSRA report shared that Black Duck Audits conducted in 2019 found that 91% of the codebases examined contained components that were more than four years out of date or had no development activity in the last two years. Besides adding to the security risk, the danger of getting too far behind in versioning is that the simple act of updating to the latest version can introduce unwanted functional changes, such as the disappearance of key features.
Engaging with the communities whose open source projects your organization relies on is one of the best ways to ensure those projects stay healthy, vital, and up to date.
Common open source database security problems
Steve notes that there are some common issues around databases and security:
- Missing access control – several open source databases ship as standard with no default requirement to set passwords. “In the rush to get implementations done and overcome strange error messages, this may get missed, leaving data sets available to access if you are not careful.”
- More privilege than needed – “it’s unlikely that your application user needs “root” or “super” level access on the database but in the rush to get past errors, the instinct is to use the “big hammer” approach and grant far more power than is needed. This puts the entire database at risk if the account is compromised.”
- No version control – updating databases to the latest version is a simple way to avoid potential security issues. However, developers may not think to track this over time or may miss older database instances over time. Tracking your instances and knowing any that need updates is therefore worthwhile.
- Misconfiguration – even if you have access control and an up to date instance, a misconfiguration can lead to data leakage if you are not careful. This can be something as simple as forgetting to turn off an application debugger in production, which can leak highly sensitive information to the wrong people.
- Poor security settings – with external authentication plugins there’s no reason to share accounts and many popular open source databases can control access centrally and provide a great audit log of who did what and when but that means nothing if everyone logs in and runs commands as “admin”.
Don’t forget to secure passwords!
According to Steve, developers need to consider things like “least privilege”, “sanitizing inputs”, “who will have host access”, “best protocols to use” and the like. “In most cases, devs tend to put the most energy into the most complex topics and inevitably leave silly things open, like leaving passwords in logs or on filesystems that are world-readable.” This was confirmed in a 2019 data breach where an ElasticSearchserver was left exposed online without a password. More recently, over five billion records were exposed after a U.K.-based security firm inadvertently exposed its “Data breach Database”, which stored security incidents without password protection. In May this year, Security researcher Troy Hunt discovered an open Elasticsearch database containing around 22 million of email records.
The importance of secure by design
A strategy around ‘secure by design’ is a must. From there, frameworks around security models can be established and sufficient documentation can be made available on how to adhere to the guidelines for anyone that wants to contribute. Steve notes that “At the end of the day though, security is made or broken at the individual level. The peer-review process will catch many things, but even with the best policies around security and development in place, it’ll only be as good as the coder that creates it and the reviewers that double-check the work. “
According to Steve, the minimum best practice testing needs to include:
- Positive and negative testing,
- Privilege level testing
- Scanning for hardcoded passwords/keys
- Penetration testing
- Vulnerability scanning of the code as well as any third-party libraries used (XSS, Injection attacks, etc).
Steve asserts that while exploits can be quite complex, one of the best approaches to security is simplicity:
“The more complex the use cases, the more likely one is to miss a combination that can put an application or database at risk. Obviously, it’s not always possible as needs increase, but most organizations I know of have *someone* in a security role. However, I’ve seen so few engineers take advantage of that fantastic resource and get ideas of what to do to program defensively. This collaboration eliminates a lot of the guesswork on what to be considering when you harness that expertise.”
Microsoft recently announced it will join forces with many leading industry partners to create the Open Source Security Foundation (OpenSSF). The OpenSSF brings together work from the Linux Foundation-initiated Core Infrastructure Initiative (CII), the GitHub-initiated Open Source Security Coalition (OSSC), and other open-source security efforts to improve the security of open-source software by building a broader community, targeted initiatives, and best practices. Microsoft is proud to be a founding member alongside GitHub, Google, IBM, JPMC, NCC Group, OWASP Foundation, and Red Hat.
The OpenSSF notes that the open source software that ultimately reaches end-users has a chain of contributors and dependencies. It is important that those responsible for their user or organization’s security are able to understand and verify the security of this dependency chain. The initial technical initiatives will focus on:
- Vulnerability Disclosures
- Security Tooling
- Security Best Practices
- Identifying Security Threats to Open Source Projects
- Securing Critical Projects
- Developer Identity Verification
Looking for Resources?
The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software. They’ve compiled an extensive list of automated vulnerability detection tools that are free for open source projects.
Also, read this article to discover how to get started with Open Source!
