devopsy.kinsta.cloud

Tag: open-source components

  • SCA, SBOMs and Floodgates

    SCA, SBOMs and Floodgates

    Two criteria are used to determine pervasiveness of a new idea. Availability of an easy-to-understand solution and customer need. Given both of these items, what might be a market-differentiating feature available in a single IT/DevOps market becomes a wave of options in multiple markets that an organization can (and should) choose from.

    What started this off? Well, I’ve been working in areas that involve expansive use of open source. This is pretty much to say, “I’ve been working in IT,” at this point, but that’s a different blog. The thing is, today, working with open source implies a complex software infrastructure that, traditionally, no one actually had a handle on. What is directly included in that project? What is indirectly included in that project?

    But then we had some pretty stellar security issues related to commonly-used open source. And we had commonly-used programming language modules pulled out from under hundreds of thousands of applications. Then we started paying attention. Or, more accurately, then we finally set out to fix a problem we’d been ignoring.

    This market is a bit confused by different use cases and the fact that there are two toolsets to achieve what IT sees as one job. So let’s talk about the complexities, just for clarity. First off, a software bill of materials (SBOM) is the list of what is included in a software project. The complexities here are twofold. From a programming perspective—meaning tools designed to be used by programmers during development—“included” means libraries, modules, etc. that the application calls on to do what the organization needs. These are “included” in the build process. From a systems perspective, “included” means everything installed on the image when it goes to production. These are similar but very different lists. The developer list is a subset of the production list because all of the items in the development list are included in production, but the production list will have other software that is used to support the developed application. Think of the application having all of its libraries and modules, but assuming SSL termination will be there. Because it will. In the image. That’s the difference. Many products have had an internalized version of SBOM for years now—developer security tools and release scanning tools pretty much require a list of everything they need to scan. But few made these lists public, and many tools did not have them.

    Software composition analysis (SCA) takes the SBOM and adds value. While a list of everything included is useful, a subset that lists everything that’s actually used is more to the point, for example. So is a list of flaws found in included libraries/packages and suggestions on how to address them. This can be done from either the source or production SBoM side, depending upon implementation.

    Once the value of both tools was made clear—and implementations existed that showed both how to implement them and what the benefits were—the floodgates opened. Now there are few DevOps or security tools that do not offer one or both of these features. That gives us an embarrassment of riches. Which tool(s) do we use for compliance and security review? As we do with data, I’m going to suggest that a single product is chosen as the “source of truth” and run with. At this time, I do not have suggestions on which ones are better for this purpose, just a suggestion that if you use different ones for different purposes you are likely to get different results, and that isn’t going to help simplify things at all. So, look at the ones you already have access to—they’re in enough products that you likely have more than one available in your existing infrastructure—and make it your standard.

    Then, use that standard to help monitor use of open source. Monitoring can help with open source licensing, with application and infrastructure security, with image simplification and with compliance. So strip unused packages out of images and clean libraries that are no longer called out of your build process. Respond to issues faster, and keep that application infrastructure you’ve been nursing along humming. And keep kicking it; your users should appreciate it, even if they do not.

  • Leveraging the Open-Source Ecosystem When Developing Modern z/OS Applications

    Leveraging the Open-Source Ecosystem When Developing Modern z/OS Applications

    Developers today are under great pressure to create apps faster than ever before, and they must continuously update them, adding new features and incorporating new technologies. Many companies have adopted DevOps, cloud-native architectures, and low-code development solutions to accelerate the development and updating cycle. But another critical aspect to modern application development has been to take advantage of the numerous benefits of using open-source software.

    The advantages of open-source software include fast cycles (compared to many commercial applications) for new versions, more responsiveness to add user-requested features, frequent updates to accommodate new technologies, and a large developer base that brings varied and diverse approaches to solving problems. Then there are the business benefits. Open-source software is often lower cost, more flexible (less chance of vendor lock-in), and more transparent than commercial offerings. Additionally, open-source software perfectly complements today’s cloud-native applications that bring loosely coupled components together as an alternative to the monolithic applications of old.

    Such benefits have driven up the use of open-source software in enterprises, particularly over the last several years. A number of past studies highlighted the wide-scale and growing use of open-source software. One study found that essentially all (99 percent) of the codebases examined contained at least one open-source component, with open source comprising 70 percent of the code overall. And in another survey released last year, 75 percent of enterprises said open-source software was very or extremely important. And 77 percent of companies in the same survey said they planned to ramp up their use of open software over the next 12 months.

    Open source and z/OS

    The enthusiasm for open-source software extends into the z/OS application development community for all the same reasons as with general apps. Namely, there is a vast ecosystem of solutions and developers that a company can rely on when developing modern z/OS applications.

    In particular, there are a number of z/OS open-source software groups, projects, and efforts to draw from.

    To start, there are open-source programming languages and tools like Python, Git, and cURL available that let developers use the power of z/OS systems without learning new skills.

    There are groups like the Open Mainframe Project, which aims to be a focal point for deploying and using Linux and Open Source in a mainframe computing environment.

    One project from this group is Zowe, which is an open-source framework for the modern z/OS system. Zowe bridges the divide between modern applications and the mainframe, providing easier interoperability and scalability among products and solutions from multiple vendors.

    And there are open-source projects like Ansible, an open-source community project for app deployment, configuration management, and orchestration. It is available for z/OS. Ansible allows developers to automate z/OS applications. With Ansible, developers can use existing JCL, REXX, and z/OSMF to automate z/OS-based software. This lets a developer take a common approach to hybrid applications and lets them integrate z/OS into an enterprise automation strategy in a consistent way.

    A great advantage of using these open-source z/OS offerings is that developers with widely available skills can create new z/OS apps. That is a major plus these days as the pool of talent that has native z/OS skills is diminishing. Many of the people that came up on mainframes and coding for z/OS are retiring. And many younger developers are learning on the job to program for z/OS.

    Enterprise capabilities are still a must

    As with many open-source solutions ranging from Linux to Apache webserver to Kubernetes, companies that use them must complement the solutions with additional capabilities to ensure availability, security, and performance.

    A do-it-yourself (DIY) approach is certainly possible. But that requires a great amount of time and resources. It also requires skills that a company may not have. Hiring for those skills or getting internal staff trained in these areas also is costly and time-consuming.

    The alternative is to partner with a technology provider that brings z/OS expertise, a knowledge of open-source, and the features and people to make the solutions enterprise-ready.

  • Yes, You Do Need SCA

    Yes, You Do Need SCA

    We often go to restaurants and treat ourselves to unfamiliar and exotic foods made with ingredients we’re only vaguely aware of. A chef and their team (or a manager and their crew) are our vouchsafe that what’s in there isn’t deadly. Most of the time, that works out just fine; but, very rarely, we end up paying the price. The same is true for food brought home from the supermarket, though for lesser illnesses it is harder to track because they’re not clustered like restaurant customers. While it is indeed exceedingly rare for the results to be fatal, the CDC estimates that around 3,000 people die of food-borne illnesses in the U.S. each year, and millions more are made ill. The U.S. has incredibly safe foods, and yet, we still have these illnesses. Simple things like leaving ingredients out too long, or consuming food sourced from a contaminated production facility can cause problems, even in an otherwise safe environment.

    Our code is similar—how it is created and consumed—and increasingly falls in this category. We rely upon a ton of sources for the systems that run our networks, and, quite often, there is no one to tell us how safe our sourcing is, or if changes are happening beneath that escape our notice.

    This is why we absolutely must have software composition analysis (SCA). If no one else is going to stand up and verify the safety of all that code we are pulling in, then we need to at least be aware of what is there. We need to understand the inter-relationships of pieces of underlying software, both the known and the unknown. Some libraries are so ubiquitous that you are using them and likely don’t even know it. But that’s not good management; knowing what you have and taking care of it are increasingly becoming a core part of IT. Knowing what alternatives are available in case something goes wrong with your preferred (or automatic) inclusion is imperative for continuity, making SCA a critical part of continuity planning along with the fact that it’s just good business practice.

    The good news is, if you are using any of the major code scanning tools from the DevSecOps space, you either already have SCA available to you, or you can buy it as an add-on from the same vendor. Hit their website and find out.

    Your systems are out there, every day, serving the needs of your users. Protect those users from unforeseen circumstances like vendor issues, open source changes, security vulnerabilities and nested dependencies. While the vast majority of open source is safe and secure, we use so much of it—and the tools we use link in so much of it—that it’s almost certain there is a bomb hidden somewhere in your code. Think of it like the food-borne illness example above: Would you eat at a restaurant that said “Yeah, 90% of our food is safe, but we’re not sure about the other 10% …”?

    You’re building astounding things, and keeping the world moving. Don’t stop, but don’t let your guard down, either. Know what is running in those apps, what its vulnerabilities (both security and downtime) are and what you can do to mitigate those weaknesses–so you can keep making astounding things rather than spend your time fixing what is already there.

  • Open Source License Compliance Tips for DevOps Pipelines

    Open Source License Compliance Tips for DevOps Pipelines

    Open source components are used in most modern organizations, either included directly into software as code or as tools integrated into workflows. In DevOps environments, often a combination of the two occurs. These components can help speed development processes, provide functionality that isn’t otherwise available and decrease operating costs of teams.

    To successfully implement open source components, in software or pipelines, teams need to carefully evaluate what projects are included. Although most open source is free and supported by developer communities, there is no oversight guaranteeing that components are well-made and licensing can vary widely. This means that teams are responsible for ensuring that code is safe, stable and implemented legally.

    DevOps and Open Source Software Development

    When you are considering including open source components in your projects and pipelines, it is important to evaluate those components first. A well-developed evaluation process can help teams verify open source components and protect from:

    • Security vulnerabilities—Components are made by a community of developers, many of whom do not have extensive security knowledge. Additionally, because projects are worked on by many developers, code may not be uniform, creating bugs that can turn into security vulnerabilities.
    • Operational risks—Open source projects are maintained voluntarily. This means that project support may wane or unexpectedly drop. Additionally, updates and patches may not be released as reliably as with proprietary software. Since continued support is not guaranteed, you may be left with significantly more responsibility for maintaining and updating components that you originally planned for.
    • Legal risk/license IP compliance—Not all components are freely available for use by every organization or project. If you use these components unlawfully you can later be held accountable for breaking license agreements, even if you were unaware of doing so.

    Why Open Source Compliance Is Important

    Open source license compliance and legal risk are especially important and complex for commercial development teams. There are more than 200 open source license variations, each with different standards for when projects can be used, by whom and in what capacity. Compliance strategies ensure that you are aware of the licensing requirements of any component you use.

    In particular, the things you need to be aware of when it comes to open source compliance is whether projects can be included in commercial products or used by teams of your size and type. If projects cannot be used in commercial projects or require projects to be made open source upon inclusion, you are risking your own intellectual property.

    Including open source projects against license can open you to legal action from project maintainers, contributors or third-party organizations. For example, some projects are part of a dual-licensing strategy with companies looking to protect their own financial interests. Or, cases may be brought as a means to raise awareness about open source licensing by concerned community members.

    Another possibility is being actively targeted for financial gain. Some projects are contributed to by open source trolls, software developers who have made a business of suing for license non-compliance. These developers take advantage of licenses such as GNU General Public License v2.0 (GPL-2.0), which terminates usage and distribution rights when breached, enabling developers to sue to stop distribution or to demand a portion of profits.

    Open Source Compliance Tips for DevOps Pipelines

    There are several practices you can implement to ensure that your pipelines and products are in compliance when it comes to open source. These practices are especially important to integrate throughout your pipeline to help identify and correct any issues that may exist before products are pushed to production. Below are some practices to get started with.

    Create an Open Source Review Board (OSRB)

    An OSRB is a group responsible for creating and enforcing open source policies and procedures within your organization. These boards often include members from development, operations, legal and management teams.

    OSRBs can serve as advocates for open source use with executives and stakeholders. They can also serve as a source of information for teams looking to incorporate or contribute to open source projects. These boards can help you ensure that you remain in compliance while deriving the greatest benefit from open source.

    Incorporate Compliance Processes Throughout Development

    Compliance policies should be created and incorporated into all steps of the software development life cycle (SDLC). These policies should outline how components are vetted, by whom, how and when components can be included, and how tracking is done.

    Ideally, compliance processes and policies should be built into your pipeline processes. For example, by returning builds to developers if they include blacklisted licenses. By incorporating compliance, you reduce the chance that it is overlooked and minimize interruptions to productivity. Incorporation also helps you ensure that licensing issues are found sooner rather than later, minimizing the impact if components need to be replaced or removed.

    Create ‘Playbooks’ for Commonly Used Licenses

    While there are many licenses that open source projects can fall under, there are several that are significantly more common than others. For example, MIT or Apache—for these licenses, you can simplify compliance procedures by creating playbooks.

    Playbooks outline the details of licenses, including license grants, obligations, restrictions and patent impacts. When a developer wants to include a component, they can use these playbooks to quickly determine whether that component is eligible for use. While this won’t eliminate all legal questions when it comes to licensing, it can significantly reduce how often you need to confer with legal counsel about inclusions.

    Use Software Composition Analysis (SCA) Tools

    SCA tools can help you identify open source components in your own products and in any tools you adopt. These tools enable you to scan source code to determine what components are inside and create an inventory that you can then use to verify compliance. As a bonus, these tools can also help you identify components with known vulnerabilities, which you can then mitigate.

    SCA is especially helpful when you are newly implementing open source compliance policies. It can provide information on the types of components you are already using and help you ensure that those existing components meet your newly applied standards. Some tools even enable you to set up alerts for license conflicts or irregular version use, making verification easier.

    Conclusion

    Open source compliance is a critical component of most DevOps implementations. To ensure compliance, teams need to carefully choose and then properly keep track of open source components. You can do that by creating an open source review board (OSRB), which can help enforce open source compliance policies. You should also incorporate compliance throughout your pipeline, create playbooks for commonly used licenses and leverage SCA tools.

  • 5 Best Practices for Managing Open-Source Components

    5 Best Practices for Managing Open-Source Components

    In today’s connected world, software development environments focus a lot on faced-paced development. Organizations that adopt agile development practices such as DevOps and use Open-Source (OS) software and components to their advantage have a much better chance of keeping up with demand and shorten the Software Development Lifecycle (SDLC).

    However, incorporating OS components into applications does not come without risks, as they often contain bugs or vulnerabilities, and are highly exposed to exploits. In this article, we will cover what is Open-Source Software (OSS) and OS components, discuss the importance of security for open source and cover five best practices for managing open-source components.

    What Is Open-Source Software?

    Open source refers to any software with accessible source code that anyone can modify and share freely. You can head over to the Open Source Initiative (OSI) and see a detailed list of criteria for the definition of OSS. While OSS allows many more modifications over proprietary software, you must still accept the terms and conditions defined in its license.

    Some estimations suggest OSS adoption saves $60 billion dollars for consumers per year, while about 96% of all commercial applications contain some components or elements of OSS.

    The Benefits of Open-Source Components

    Open-source components are software units that meet the definition provided by the OSI. Modern development environments put a lot of pressure on developers to build and deploy applications more quickly. To successfully achieve their goals within short software release cycles, developers frequently use OS components.

    The Importance of Security for Open-Source Components

    OS components are incorporated into the vast majority of software and applications. Even though they allow developers to be more efficient and get more done, they can also introduce new vulnerabilities and jeopardize the integrity of the entire code.

    Since OS components are developed in a distributed system, they are often more vulnerable to exploits than proprietary code. Some of the reasons for this are:

    • Distributed development: Compared to a distributed OSS developed by many individuals, it is much easier to track and manage a code developed in-house and ensure you follow policies and protocols.
    • Fast release cycles: OSS development is much quicker and agile, which means that very often, by the time a new software release passes all the quality and vulnerability checks, it has already become obsolete with the release of a newer cycle. This makes it almost impossible and in most cases useless to run the necessary tests and ensure the safety of using the code.
    • Lack of quality standards: OSS elements do not pass the same quality and standard checks as proprietary code. Thus, unless you evaluate each OS component before implementing it, you can often incorporate low-quality code that is exposed to vulnerabilities, lowering the overall quality of your code.
    • The double-edged sword: When members of the open-source community discover a vulnerability, they publicly share the details of the problem in online forums to help developers learn about the risk and how to patch it. Unfortunately, this solution is often a double-edged sword. While this is a step in the right direction, it exposes the details of the vulnerability to threat actors as well, who can exploit it against systems that have not yet patched the vulnerability.
    • Lack of security measures: The problem with OSS is even greater for smaller companies, who prefer to use it to save time and resources but lack the necessary security measures to ensure the components they are implementing are secure enough to be implemented into the code.

    Now, let’s take a look at the five best practices for OS components management.

    Form a Policy

    Establish a clear policy on how to incorporate and manage OS components. This step will give usage guidelines to your developers and ensure OSS elements are incorporated responsibly without damaging code quality. Additionally, if you are facing problems with OSS elements, this policy can act as a playbook and give instructions to your security teams on how to handle the threat.

    Carefully Choose Software

    It is important to choose the right software for you. While it might be tempting to use many kinds of software and enjoy all their possible benefits, you have to consider your requirements and ensure the software you use can answer all your demands. You should consider the amount of support you require and the risks you might face. One of the most crucial aspects is how secure the software is. A good way to measure the software’s security is the Open Web App Application Security Project (OWASP) dependency-check, a utility tool that identifies project dependencies and checks if they contain any open-source vulnerabilities.

    Track and Update OS Components Regularly

    Track your OS components throughout the entire product life cycle and ensure transparency to find critical security vulnerabilities. Updating OS components versions frequently is typically the best way to deal with bugs and vulnerabilities.

    Forking

    One of the best features of OSS is (as long as you keep up with the policies) you can modify the source code and customize the software to fit your needs. Thus, you can take software intended for specific use-cases and modify it to provide a better solution for your situation. However, this process can be intensive and take effort and time. Thus, before you attempt forking, consult with other community and team members to ensure you have the right idea and execution.

    Use Automated Tools

    Cybersecurity is highly time-sensitive—the first moments of dealing with an attack are the most critical. Automated tools, such as Security, Orchestration, Automation and Response (SOAR), can help you identify threats quicker and make mitigation efforts much faster to minimize and dramatically minimize the attack’s potential damage to your system. You can also use automated tools to enforce policies and check your OS components for vulnerabilities, making the process much faster and more secure.

    Wrap Up

    OSS and OS components have many advantages for developers and facilitate agile development. However, the flip side of their ease of use is the danger they pose in terms of open-source vulnerabilities. To mitigate this risk, you should incorporate the right practices for managing OS components into a clear strategy. This will allow you to enjoy all the benefits of OS components without exposing your application, network and systems to unnecessary risks.

    — Ilai Bavati