To ensure the ZeroNorth™ platform embeds seamlessly into any development process and works with security tools an organization has implemented, we have strategic alliances and technical integrations with best-in-class providers. These relationships span infrastructure, application security, code review and notification technologies and enable ZeroNorth to deliver a holistic view of security postures with any tool an organization has implemented.
WhiteSource provides continuous open source software security and compliance management. Integrating WhiteSource and ZeroNorth means our mutual customers can have better understanding of and manage their security risk and exposure with one view.
Here WhiteSource offers insights into how to win at open source security.
The Tools, People and Game Plan: How to Win at Open Source Security
Considering the fact that 84% of all cyber-attacks are on the application layer, it’s no surprise that application security is keeping organizational security execs up at night. Establishing policies that can be enforced across your organization and have a real impact on the security of your products can be a difficult process, especially as teams are faced with limited resources with which to get the job done. While there will always be gaps, nobody wants to make the wrong call that leads to a breach.
One aspect of application security that is often overlooked by both development and security teams, is open source security. Open source usage has become an integral part of development as open source code provides developers with a free, customizable resource that helps them create and support their organizations’ quality products within competitive time frames, to an ever-demanding market.
According to a recent report from Forrester, 60%-80% of the average software product is composed of open source components. Although open source has been central to increasing software developers’ productivity, it has also introduced new challenges into the software development process. The problem is that most software development and security teams are still learning to adapt to these new challenges, and don’t always know how to properly address them.
Shifting Left Open Source Security
Security is never a one-stop-shop. Similar to any organizational security policy, open source security requires teams to pay attention to all the moving parts and make an effort to address it throughout different phases of the application lifecycle management (ALM). In order to make sure you’ve got open source security covered, you need to pay attention to the tools that you’re using, the processes you have in place, and of course, the people that are behind your code and security practices.
Here is a quick list of the three aspects that organizations need to invest in if they want to make sure open source security doesn’t become the weak link in their operation.
#1 The Tools: Automate
As DevSecOps practices are adopted throughout our industry, more and more teams are understanding the importance of shifting security left and implementing that principle throughout the software development lifecycle (SDLC). A big part of this is incorporating automated continuous tools in the development process.
Teams are beginning to understand that the earlier you test, the safer you are. This means that you have to implement the right tools and processes. Unfortunately, many organizations don’t realize that the testing tools that work for their proprietary software are simply not the right fit when it comes to open source security.
Vulnerabilities in open source components are different than those in proprietary software, and application security tools like SAST, DAST, or others don’t cover vulnerabilities in open source components.
While the open source community continuously updates and publishes security fixes to open source projects, the open source vulnerabilities that they fix aren’t published in one centralized location.
It’s difficult to impossible for a team to manually track their open source usage and components, not to mention updates on vulnerabilities and on their fixes. Response time is critical since a vulnerability published today might very well be exploited by hackers tomorrow, necessitating tools that can keep security teams a step ahead of the attackers.
In order to manage open source security and continuously track all open source components, organizations need to incorporate Software Composition Analysis (SCA) tools early in the development lifecycle. SCA tools continuously track the open source components throughout your SDLC, including any security risks that arise, enabling your team to mitigate any open source security vulnerabilities before hackers get a chance to exploit your organization or product.
#2 The People: Collaborate
Incorporating the right tools throughout the development cycle will definitely help an organization to tighten up security, but that’s not the only aspect we need to focus on. All due respect to machines, it’s still people that are creating the product.
DevSecOps is not just a buzzword. It refers to different teams working together and sharing their knowledge to make sure all three disciplines shine throughout the ALM, and not only in what used to be their respective domains. The all-hands-on-deck approach, promoting cooperation and shared knowledge between Dev, Sec and Ops, helps organizations create stable and secure products within the aggressive time frame that customers today expect.
The older waterfall approach required each of the professionals to stay in their lane, believing that anything else would mean too many cooks in the kitchen. Today, organizations can’t afford to keep security out of the picture or wait for the development process to be complete before they start poking and prodding at a finished product to check for vulnerabilities.
This is particularly true for open source usage, where developers can go to any number of repositories and choose any component for their product. Unless security and development teams are mindful of open source security risks, and agree together to follow through with best practices, they’re likely to find themselves in a time-consuming and dangerous game of hot potato later on.
Revising the knowledge and tasks of roles in an organization is also a process that might get some resistance in the beginning and transitioning to a new mindset is always a challenge, but not one that organizations today can afford to avoid.
Adopting a new and secure DevOps approach requires all players to allow room for the expertise that their colleagues bring to the table and learn as a team how to ensure that the process and end product are up to everyone’s standards. A product is only as good as its weakest link, or its weakest team. Stakeholders need to keep this in mind and make sure that the organization’s transition to Dev, Sec and Ops teams’ cooperation happens.
#3 The Game Plan: Prioritize
So you’ve finally adopted an automated SCA tool to manage your open source security. You have regularly scheduled automated reports about your open source components, and you even get alerts, along with information for remediation, when a vulnerable component is found.
It seems like you are all set. It’s a good start but you’re not at the end of your journey yet.
Most SCA tools will provide you with a long list of the open source vulnerabilities in your inventory. It can be a tedious task of reviewing each item and updating it as needed. Any software developer or project manager will tell you that these updates can guzzle up a lot of your teams’ valuable time.
Just as important as locating vulnerabilities, is the need to prioritize how you go about addressing them so that the real emergencies get the attention that they need.
A good SCA tool can help you with prioritization in a couple of ways. You can set it up so that it addresses your organization’s specific policies, sending you real-time alerts if and when the issues that really concern you arise.
Another way a good SCA tool will help you manage your open source security is to pinpoint the issues that will really cause pain, shining a light on the functionalities that really impact your product, rather than presenting you with a list of every single vulnerable open source component in your inventory.
This type of tool will help your team cut remediation time by providing you with actionable insights that will lead you straight to the root of the problem.
Open Source Security: Check All the Boxes
As you can see, there are a lot of moving parts to managing your open source security. When attempting to come up with the best application security strategy for your organization, it’s extremely important to remember how prevalent the use of open source components has become and be mindful of the security practices open source usage requires.
When you have the right tools, processes, and attitudes in place, you can go back to focusing on making sure you deliver the best product to keep your customers coming back for more.