From software security to open source, code quality, regulatory compliance, and the future of software development, here are our top stories from 2019.
The Open Web Application Security Project (OWASP) is a nonprofit community of software developers, engineers, and freelancers that provides resources and tools for web application security. Every few years, OWASP releases a report on the 10 most critical web application security risks. The latest, OWASP Top 10 2017, was released in November 2017 (our own Andrew van der Stock was involved in its creation).
You might think that because the web application development landscape changes so quickly, the list of highest web app security risks would follow along. But that’s not the case. Most of the issues in the OWASP Top 10 2017 are the same as (or very similar to) the issues in the first list from 2004. The web has come a long way since then, but web app security has yet to catch up.
Learn more about the OWASP Top 10 web application security risks.
Application security is a crowded, confusing field. And it grows more confusing every day as cyber threats increase and new AppSec vendors jump into the market. Securing your applications against today’s cyber threats means facing a veritable jungle of products, services, and solutions.
If you’re setting off into the application security jungle, don’t leave home without a map. Our Complete Application Security Checklist outlines 11 best practices that describe how to secure your applications and protect your data in the current threat environment.
When we audit codebases, we focus on identifying all open source and third-party components along with their associated licenses. As much as possible, we also identify how those components are used so we can determine if there are any potential license conflicts. This gives our customers actionable information about the open source and third-party code in the codebases that we audit.
As part of an audit, we give each component that we find a category and status according to the risk based on its combined license and usage. These categories and statuses help customers determine level of risk and prioritize any required mitigation. Let’s review how we open source license risks can be categorized.
Read more about how to categorize open source license risks.
Jay Kelath, director of product security for Dow Jones, and Kyle Lai, head of KLC Consulting, who works mainly with large energy firms, agreed to talk with us at the RSA Conference in San Francisco about trends, challenges, obstacles and solutions to the ongoing, never-ending journey to better application security, along with a bit about their experience with the BSIMM. Here’s what they had to say about challenges, threats, regulation, DevSecOps, and the future of software security.
See what the experts say about application security trends from 2019.
Many developers draw a distinction between code quality and code security. Traditionally, embedded development and QA teams focused on quality, as software defects in embedded devices can cause life-threatening consequences. By contrast, security was most often a concern with web and commercial applications that handle sensitive customer data.
However, because customers now rely heavily on interconnected web and embedded applications, all development teams should be addressing both code quality and code security.
U.S. data privacy law is a mishmash of federal, state, and industry regulation. Should we enact a single universal federal data privacy law like GDPR? Here’s what 11 experts say about the state of data privacy in the U.S., what our destination should be, and how to get there.
Organizations seeking to curb the risks of an ever-expanding attack surface need to take a hard look at their application security practices. According to Forrester’s Show, Don’t Tell, Your Developers How to Write Secure Code, 73% of security decision-makers in organizations with more than 1,000 employees say improving application security capabilities and services is a top or critical priority. This isn’t surprising, considering another Forrester survey found that the two top causes of security breaches were direct attacks on web applications and taking advantage of exploitable software vulnerabilities.
OWASP says an application security vulnerability is “a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application.” MITRE, which maintains the CWE Top 25 list, defines software weaknesses as “flaws, faults, bugs, vulnerabilities, and other errors in software implementation, code, design, or architecture that if left unaddressed could result in systems and networks being vulnerable to attack.”
These are certainly useful definitions to know. But they don’t add anything particularly actionable for software developers on their journey to secure coding. That’s where the security vulnerability lists like OWASP Top 10 and CWE Top 25 come into play. These lists lay out the most critical types of security vulnerabilities to keep in mind as you develop software. But some application vulnerabilities warrant more scrutiny and mitigation efforts than others.
Read more about different types of security vulnerabilities.
Even with GDPR, CCPA, and many other regulations in place or soon to be in place, it’s still not time to retire the mantra “privacy is dead.” Personal information—health, financial, location, affiliations—is no less vulnerable to cyber criminals. Indeed, there are so many headlines about data breaches and ransomware attacks that most of us have grown numb to them.
And while there are multiple reasons, most of them come down to a single word: compliance. Rules are only effective if everybody follows them—all of them, all the time.
That’s not easy. Regulatory compliance is complicated, expensive, and full of challenges. Four years ago, experts were talking about “compliance fatigue,” given the number of standards and regulations organizations had to follow regarding the collection, sharing, and security of data.
Learn more about the regulatory compliance challenges that organizations face.
If you’re a software developer, you know the open source components and libraries you use to build software are governed by different open source licenses. But do you know all the license details? In particular, the technical and somewhat convoluted licensing conditions that could pose compliance challenges?
The main problem is that open source licenses are subjective. Their interpretation depends on the technical usage of the licensed software. So, unless you’re a legal expert, it’s difficult to determine the legal risks of using open source software. What developers need is a broad classification of licenses based on the risks they pose in terms of legal compliance.
Here, we’ve categorized the most popular open source licenses into three broad groups depending on their terms and conditions and their potential legal risks.
A software bill of materials is a list of all the open source and third-party components present in a codebase. A software BOM also lists the licenses that govern those components, the versions of the components used in the codebase, and their patch status.
Any organization that builds software needs to maintain a software BOM for their codebases. Organizations typically use a mix of custom-built code, commercial off-the-shelf code, and open source components to create software. As one principal architect of a leading software supply chain provider notes, “We have over a hundred products, with each of those products having hundreds to thousands of different third-party and open source components.” A software bill of materials allows organizations to track all the components in their codebases.
Learn more about what’s in a software bill of materials.
“The beauty of software engineering is that you can pretty much pick any domain,” says Behshad Rejai, VP of engineering in the Synopsys Software Integrity Group. “Your software engineering skills can apply to any domain. Over the course of my career, I’ve moved from automobiles to aerospace to EDA to software security.”
For example, after joining Synopsys, she started as a first-level manager, then progressed up the corporate ladder to become the VP of engineering in the Software Integrity Group. When she announced that she would retire this year, we asked her to reflect on her career and all the changes she has seen in how software is developed in her 36 years of experience.
Read what Behshad Rejai says about the past, present, and future of software development.