Learn how to compile and package your Linux application for distribution with Red Hat Package Manager.
Read More at Enable Sysadmin
Learn how to compile and package your Linux application for distribution with Red Hat Package Manager.
Read More at Enable Sysadmin
To advance your sysadmin career, focus as much on communicating well as on things like solving issues and maintaining cables and code.
Read More at Enable Sysadmin
Enhancements include building images and tearing down pods with play kube and support for Kubernetes-style init containers.
Read More at Enable Sysadmin
Software Metadata Standards Wrap Up Bigger Connections
You’re in the news. But not with the headline you want.
You’re not getting attention because of your choice of text editor or the number of spaces you use to indent code blocks. However motivating those preferences are for you and me, the non-technical world sees them as private choices. You find your code in the headlines for a different and unpleasant reason: open source dependency management.
We have dependencies, of course, because we know not to “reinvent the wheel”; instead, we software experts re-use the implementations others have created. However, when done poorly, dependency management introduces more risk and degrades the quality of your application. For example, failure to comply with license requirements might be the problem. Even worse: the absence of a license tied to a component you embedded in your application. In both cases, there are potential legal implications.
Still more traumatic is a media headline announcing that a vulnerability just breached your organization in one of those dependencies. Projects frequently re-use software components to simplify or accelerate development; but sometimes, it can have detrimental results by introducing said vulnerabilities.
That’s not all: suppose you are experienced and thoughtful enough to recognize this hazard and commit to good dependency management. It turns out that’s a harder problem than might first appear, and certainly not the kind of thing that can be slipped into a project on its last days, without significant time or other costs.
How, for instance, does an industrial oven manufacturer communicate that one of its products depends on a particular library with a known vulnerability? How does it say that it does not have such a dependency? One of the difficulties comes from mixing open and closed information sets. What happens in a scenario where an automotive chip uses an open source sorting algorithm, but the auto manufacturer wants to keep the use of that algorithm proprietary?
Without a better alternative, any discussion about the algorithm has to occur under cover of a non-disclosure agreement (NDA), often one written specifically for the business and technical situation. Where developers investigating a particular piece of software might be accustomed to connecting to GitHub and inspecting the source in question in a few seconds, even the simplest proprietary questions sometimes take months of legal, security, and compliance negotiation to begin to examine. “Manual” inspection, in any case, is unscalable. The average application contains 200 OSS components, and each component might manually take three hours to inspect. Does your project have a better use for 600 hours of effort? Open source truly begins to pay off when it’s inspected not just by expert engineers but by automatic tools.
Recognize, moreover, that transitive dependencies make dependency management a harder problem than first appears. Many of the most notorious breaches occurred not because anything was wrong with the source of a product or even the source of the libraries on which it depends; the vulnerability only turned up in a library used by those other libraries. Over and over again, CEOs who’ve asked, “does $SOME_PROBLEM affect us?” have received the answer, “we don’t know yet: we’re not sure where it shows up in our systems.” We need transparency about dependencies and enough intelligence and standardization around hierarchical relationships to “trace the whole tree.” Organizations must track dependencies through to the operating system run-time and sometimes down to “the silicon,” that is, the microprocessor on which the software runs.
It’s a hard problem but also a solvable one. Part of any solution is a well-defined software bill of materials (SBOM or sometimes SBoM). That’s where Kate Stewart’s career began to track this story. Stewart currently serves the Linux Foundation as a vice president of Dependable Embedded Systems. In previous assignments with such employers as Motorola, Freescale Semiconductor, Canonical, and Linaro, she frequently faced challenges that mixed technical and legal aspects. As she explained her long-time focus in a recent interview, “if open source components are going to be in safety-critical places … [we need] to be able to trust open source in those spaces …” Good SBOM practices are simply necessary for the level of trust we want to have not just in industrial ovens, but airplanes, medical devices, home security systems, and much more. An SBOM organizes such metadata about a software artifact as its identity, verification checks it hasn’t been tampered with, copyright, license, where to look up known security vulnerabilities, dependencies to check, and so on. Think of an SBOM as an ingredients list for your software. It makes those ingredients visible, trackable, and traceable. It lets you know if you have used the highest quality and least risky open source components to build your software.
Stewart and other technologists eventually began to team with specialists in intellectual property, product managers, and others. They developed such concepts in the early years of this millennium as SBOM, the Software Package Data Exchange (SPDX), and the OpenChain Specification. She co-founded SPDX in 2009 to pursue “[a]n open standard for communicating software bill of materials information ….” Among other features and benefits, these frameworks provide standard and scalable ways to discuss dependencies.
Instead of each vendor having to certify that each of its releases has been verified for security and license compliance of each of eight hundred JavaScript libraries, for example, many of the most time-consuming aspects of compliance can be automated. When a new vulnerability is identified in an implementation of a networking protocol, automated methods can largely be applied to determine which products embed known vulnerable libraries, even while we developers remain largely unaware of the details of each component and dependency they use. For Stewart, standards-based transparency and best practices are prerequisites for the security of safety-critical communities she helps serve. As Stewart observes, “you can’t really be safe unless you know what you’re running.”
Does that sound mundane? The reality’s far different: SBOM and related technologies actually play roles in events on the world stage. For example, on the 12th of May, 2021, US President Biden issued Executive Order 14028 on Cybersecurity Improvement; SBOMs play a prominent role there. The Open Source Initiative just named Stefano Maffulli its first Executive Director precisely because of the need for mature open source licensing practices. Dr. Gail Murphy argued in a recent interview that it’s time to recognize that open source software is a “triumph of information-hiding [and] modularity …” in enabling the remarkable software supply chains on which we depend. Emerging information on breaches including SolarWinds, Rapid7, Energetic Bear, and especially the latest on Juniper’s Dual-EC affair shows how disastrous it becomes when we get those supply chains wrong. The most prominent breaches in computing history have been tied to component vulnerabilities that seemed peripheral until break-ins demonstrated their centrality.
Drone strikes? Vaccine efficacy? Voter fraud? International commerce? Nuclear proliferation? Questions about software and data reliability and fidelity are central to all these subjects, not mere technical tangents.
That’s why SPDX’s management of hierarchical relationships is so crucial.
SPDX went live as an official international standard at the end of August. With that milestone, standardization lowers many of the hurdles to the successful completion of an SBOM project. Implementation becomes more consistent. “Bookkeeping” about external parts becomes largely a responsibility of the standard. Software engineers focus more on the details specific to an application. Then, as those external parts–the ingredients of an SBOM recipe–age and security vulnerabilities are discovered in them, developers can reliably track those components to the applications where they were used and update components to newer, hardened versions. What does that mean for you? In your own work, the faster you identify and update vulnerable components, the less likely the chance you will have of becoming the next breach headline following an attack.
SPDX’s standardization fits in the frameworks of the International Organization for Standardization (ISO) the International Electrotechnical Commission (IEC). ISO is a post-war transnational creation that originally focused on bolt sizes, temperature measurements, and medical supplies. ISO tracks human affairs, of course, and its attention in recent years has shifted from materials to business processes and, in this millennium, to software. IEC is a prior generation’s initiative to pursue the same kinds of standardization and cooperation, specifically in the realm of electrical machinery; the IEC and ISO often collaborate.
In bald terms, ISO and IEC matter to you as a programmer because governments trust them. The new standard is sure to make its way rapidly into procurement specifications, especially for government purchases. Suppliers become accustomed to compliance with such standards and apply them in their practices more generally. The earlier ISO 9000 collection of standards has already greatly influenced software development.
The impact and scope of ISO:IEC 5926:2021 is a challenge to understand, let alone explain. On the one hand, millions of working programmers worldwide go about their daily chores with little thought of SPDX or even SBOMs. While we all know we depend on packages, we largely leave it to Maven or npm, or RubyGems, etc., to handle the details for us. Standardization of SPDX looks like a couple of layers of abstraction, even more remote from the priorities of the current sprint or customer emergency on our desks right now.
And it’s true: SPDX is abstract, and its technical details look dry to some programmers, the opposite of the “sexy” story many start-ups aspire to.
Without this infrastructure, though, the development of many large, complex, or mission-critical projects would grind to a halt from the friction of communication about proprietary dependencies on open source artifacts. Think of it on a weight basis: as the Linux Foundation’s own press release underlines, “… between eighty and ninety percent of a modern application is assembled from open source software components.” SPDX is immensely important at the same time as it’s uninteresting to all but the most specialized practitioners.
Look to history for examples of how momentous this kind of standardization is. The US’s Progressive movement at the beginning of the twentieth century is instructive. While often taught in ideological terms, many of its greatest achievements had to do with mundane, household matters: does a milk bottle actually contain milk? Can standard doses of medicines be trusted? Is a “pound” in a butcher’s shop a full sixteen ounces? Standards in these areas resulted in more convenience and transformed commerce to enable new market arrangements and achievements. That’s the prospect for SPDX: more transparent and effective management of software dependencies and interactions will have far larger consequences than are first apparent. Notice, for instance, that while the standard examples of its use have to do with open-source software, the standard itself and the tools that support it can also be applied to proprietary software and other intellectual property. SPDX doesn’t solve all problems of communicating about dependencies; it goes a long way, though, to clarify the boundaries between technical and legal aspects.
The significance and need for secure software supply chains haven’t made SPDX’s adoption easy, though. Stewart reports that individual companies drag their feet: “why should we do something before we have to?” these profit-oriented companies reasonably wonder. Even in the best of circumstances, when an industry has largely achieved a technical consensus, “From first proposal to final publication, developing a standard usually takes about 3 years.“
Stewart herself cites this year’s Executive Order as crucial: “the one thing that made a difference” in pushing forward adoption of SPDX in 2021 was the emerging SBOM requirements that followed EO14028. Much of her own emphasis and achievement of late has been to get decision-makers to face the reality of how crucial their dependence on open source is. No longer can they restrict focus to the 10% of a proprietary product because supply chain attacks have taught us that the 90% they re-use from the software community at large needs to be exposed and managed.
Publication of a standard mirrors application development in having so many dependencies “under the covers.” It’s not just Stewart who worked on this for more than a decade, but, as I’ll sketch in follow-ups through the next month, a whole team of organizations and individuals who each supplied a crucial requirement for completion of ISO/IEC 5926:2021. When you or I think of great software achievements, our memories probably go to particular winning prototypes turned out over a weekend. Standards work isn’t like that. The milestones don’t come at the rapid pace we relish. Successful standards hold out the promise, though, of impacting tens of thousands of applications at a time. That’s a multiplier and scalability that deserves more attention and understanding.
And that’s why ISO/IEC 5926:2021 is good news for us. We still have licensing and security issues to track down. We still need to attend meetings on governance policies. Management of proprietary details remains delicate. Every project and product needs its own SBOM, and vulnerabilities will continue to crop up inconveniently. With the acceptance of ISO/IEC 5926:2021, though, there’s enough standardization to implement continuous integration/continuous deployment (CI/CD) pipelines usefully. We can exchange dependency information with third parties reliably. SPDX provides a language for describing dependency management chores. SPDX gives answers that are good enough to focus most of our attention on delivering great new functionality.
The best practices of application development applied by developers as a learned methodology can be something more than an exercise in walking a tightrope of intellectual property restrictions. Enterprise-class proposal requests become more engineering than lawyering. You have a better shot at being in the news for your positive achievements rather than the security calamities into which you’ve stumbled.
Check in over the next several weeks to learn more about what SPDX means to your own programming, how SPDX is a model for other large-scale collaborations the Linux Foundation enables, and how teamwork is possible across profit-making boundaries. In the meantime, celebrate ISO/IEC 5926:2021 as one more problem that each project does not have to solve for itself.
About the Author: Cameron Laird is vice president of Phaseit, Inc., where he implements software projects and publishes articles about the results. A long-time developer, manager, and author, he’s most recently concentrated on architectural challenges of “continuous everything”: continuous integration, continuous testing, and so on.
Clearing up confusion about Podman’s machine architecture and other frequently asked questions.
Read More at Enable Sysadmin
Imagine you have created an open source project that has become incredibly popular. Thousands, if not millions, of developers worldwide, rely on the lines of code that you wrote. You have become an accidental hero of that community — people love your code, contribute to improving it, requesting new features, and encouraging others to use it. Life is amazing, but with great power and influence comes great responsibility.
When code is buggy, people complain. When performance issues crop up in large scale implementations, it needs to be addressed. When security vulnerabilities are discovered — because no code or its dependencies are always perfect — they need to be remediated quickly to keep your community safe.
To help open source projects better address some of the responsibilities tied to security, many communities hosted by the Linux Foundation have invested countless hours, resources, and code into some important efforts. We’ve worked to improve the security of the Linux kernel, hosted Let’s Encrypt and sigstore, helped steward the ISO standardization for SPDX, and brought together a community building metrics for OSS health and risk through the CHAOSS project — among many others.
Today, we are taking steps with many leading organizations around the world to enhance the security of software supply chains. The Linux Foundation has raised $10 million in new investments to expand and support the Open Source Security Foundation (OpenSSF) and its initiatives. This cross-industry collaboration brings together an ecosystem to collectively identify and fix cybersecurity vulnerabilities in open source software and develop improved tooling, training, research, best practices, and vulnerability disclosure practices. We are also proud to announce that open source luminary, Brian Behlendorf, will serve the OpenSSF community as General Manager.
Financial commitments for OpenSSF include Premier members such as Cisco, Dell Technologies, Ericsson, Facebook, Fidelity, GitHub, Google, IBM, Intel, JPMorgan Chase, Microsoft, Morgan Stanley, Oracle, Red Hat, Snyk, and VMware. Additional commitments come from General members, including Aiven, Anchore, Apiiro, AuriStar, Codethink, Cybertrust, Deepfence, Devgistics, DTCC, GitLab, Goldman Sachs, JFrog, Nutanix, StackHawk, Tencent, TideLift and Wind River.
To learn more about how to join the OpenSSF or to get involved in one of its six working groups, listen in to this brief introduction from Brian Behlendorf recorded this week at KubeCon:
In 2021, the Linux Foundation and its community will continue to support education and share resources critical to improving open source cybersecurity. For example, this week, we also hosted SupplyChainSecurityCon, where the SLSA and sigstore projects were heavily featured.
If you are an open source software developer, user, or other community participant who just wants to help further protect the software that accelerates innovation around the world, please consider joining one of our six OpenSSF working groups, or suggest a new working group that addresses gaps in software supply chain security needs.
You can follow the latest news from OpenSSF here on our blog, Twitter (@TheOpenSSF), and LinkedIn.
The post The World’s Major Technology Providers and Converge to Improve the Security of Software Supply Chains appeared first on Linux Foundation.
Industry leaders from technology, financial services, telecom, and cybersecurity sectors respond to Biden’s Executive Order, commit to a more secure future for software; open source luminary Brian Behlendorf becomes general manager
LOS ANGELES, Calif – KubeCon – October 13, 2021 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced it has raised $10 million in new investments to expand and support the Open Source Security Foundation (OpenSSF), a cross-industry collaboration that brings together multiple open source software initiatives under one umbrella to identify and fix cybersecurity vulnerabilities in open source software and develop improved tooling, training, research, best practices, and vulnerability disclosure practices. Open source luminary Brian Behlendorf will serve the OpenSSF community as General Manager.
Financial commitments from Premier members include Amazon, Cisco, Dell Technologies, Ericsson, Facebook, Fidelity, GitHub, Google, IBM, Intel, JPMorgan Chase, Microsoft, Morgan Stanley, Oracle, Red Hat, Snyk, and VMware. Additional commitments come from General members Aiven, Anchore, Apiiro, AuriStor, Codethink, Cybertrust Japan, Deepfence, Devgistics, DTCC, GitLab, Goldman Sachs, JFrog, Nutanix, StackHawk, Tencent, TideLift, and Wind River.
“This pan-industry commitment is answering the call from the White House to raise the baseline for our collective cybersecurity wellbeing, as well as ‘paying it forward’ to open source communities to help them create secure software from which we all benefit,” said Jim Zemlin, executive director at the Linux Foundation. “We’re pleased to have Brian Behlendorf’s leadership and extensive expertise on building and sustaining large communities and technical projects applied to this work. With the tremendous growth and pervasiveness of open source software, building cybersecurity practices and programs that scale is our biggest task at hand.”
According to industry reports (“2021 State of the Software Supply Chain,” by Sonatype), software supply chain attacks have increased 650 percent and are having a severe impact on business operations. In the wake of increasing security breaches, ransomware attacks, and other cybercrimes tied to open source software, government leaders worldwide are calling for private and public collaboration. Because open source software makes up at least 70 percent of all software (“2020 Open Source Security and Risk Analysis Report” by Synopsys), the OpenSSF offers the natural, neutral, and pan-industry forum to accelerate the security of the software supply chain.
“There has never been a more exciting time to work in the open source community, and software supply chain security has never needed more of our attention,” said Brian Behlendorf, general manager, Open Source Security Foundation. “There is no single silver bullet for securing software supply chains. Research, training, best practices, tooling and collaboration require the collective power of thousands of critical minds across our community. Funding for OpenSSF gives us the forum and resources to do this work.”
The OpenSSF is home to a variety of open source software, open standards, and other open content work for improving security. Examples include:
Security Scorecard – a fully automated tool that assesses a number of important heuristics (“checks”) associated with software security
Best Practices Badge – a set of Core Infrastructure Initiative best practices for producing higher-quality secure software providing a way for OSS projects to demonstrate through badges that they are following them
Security Policies – Allstar provides a set and enforce security policies on repositories or organizations
Framework – supply-chain levels for software artifacts (SLSA) delivers a security framework for increasing levels of software supply chain integrity
Training – free secure software development fundamentals courses educating community members on how to develop secure software
Vulnerability Disclosures – a guide to coordinated vulnerability disclosure for OSS projectsPackage Analysis – look for malicious software in OSS packages
Security Reviews – public collection of security reviews of OSS
Research – studies on open source software and critical security vulnerabilities conducted in association with the Laboratory for Innovation Science at Harvard (LISH) (e.g., a preliminary census and FOSS Contributor Survey)
For more information about OpenSSF, please visit: https://openssf.org/
AWS
“Open source software plays an increasingly crucial role across the whole landscape of information security. Convening industry leaders to invest in developing policies, practices, tooling, and education around open source security benefits us all. AWS was a founding member of the Core Infrastructure Initiative in 2014, and we will now build on the relationships and investments that continue the mission by joining OpenSSF as a Premier Member. With our partners in this initiative, and as active participants in many open source communities, we will help raise the bar in the security of open source software,” said Mark Ryland, Director of the Office of the CISO at AWS.
Cisco
“OpenSSF will enable the community, across industries, to build tools and practices to secure the software supply chain for open source and beyond. This is crucial to the future of API and application security, which are fast becoming a primary attack vector for all business going forward,” says Vijoy Pandey, VP of Emerging Technologies & Incubation at Cisco. “At Cisco, we believe the application experience is the new brand, which demands better app velocity, trust, security, and availability. This belief drives our deep investment in application security and full-stack observability, which is why joining forces with this prestigious foundation and group as a trusted advisor and partner was a no-brainer for us.”
Dell Technologies
“The Linux Foundation’s focus on security is fundamental to addressing the increasing risks associated with software,” said John Roese, Dell Technologies’ Global Chief Technology Officer. “The Open Source Security Foundation’s work will help us collectively make sure critical software programs and the end to end software delivery pipeline is secure and trustworthy.”
Ericsson
“As a leader in mobile communication, pioneering and driving 5G globally, security is at the core of the network infrastructure we build and deliver to our customers. In an industry increasingly built around open source and open standardization we are fully committed to address cybersecurity vulnerabilities in a collaborative effort. We are proud to join the Open Source Security Foundation as a founding member and we look forward to continue to work with the community and wider industry for a secure software supply chain, including the open source components,” says Erik Ekudden, Senior Vice President and Chief Technology Officer, Ericsson.
Fidelity
“Open Source Software plays a critical role in Fidelity’s technology strategy. We are proud to be part of the Open Source Security Foundation and to work with others to ensure that Open Source solutions and their supply chains are safe, secure, and reliable, enabling Fidelity to better serve our customers and clients,” said John Andrukonis, SVP, Fidelity Application Architecture.
GitHub
“The world runs on software, and most of that software includes and relies on open source,” said Mike Hanley, Chief Security Officer at GitHub. “As the home to more than 65 million developers around the world, we’re excited to continue partnering across the open source community and with other Open Source Security Foundation members to power a more secure, trustworthy future that will benefit everyone.”
“We are doubling down on our OpenSSF commitment in the wake of rising open source software supply chain attacks and President Biden’s Executive Order,” said Eric Brewer, vice president of infrastructure and fellow at Google. “This decision is part of our White House pledge to spend $100 million to fund open source security foundations and follows a variety of investments we’ve made to support developers and security engineers across the public and private sectors. The OpenSSF is the best place for cross-industry leadership for these very challenging topics, and we look forward to working with the US and other governments to improve security worldwide.”
IBM
“IBM is deeply focused on developing and building highly secure hybrid cloud, AI and quantum-safe technologies that are designed to protect our clients’ most sensitive workloads both today and into the future,” said Jamie Thomas, General Manager, Strategy & Development and IBM Enterprise Security Executive. “As a long-time open source leader, IBM looks forward to working with the OSSF, our industry partners, and open source communities towards addressing the ever-increasing challenge of hardware and software open source supply chain security.”
Intel
“As a long-standing member of the open source software community, Intel contributes daily in the upstream projects we collaborate with,” said Greg Lavender, senior vice president, CTO, and general manager of Software and Advanced Technology at Intel Corporation. “Along with the Linux Foundation, we believe the Open Security Foundation (OpenSSF) is a unique opportunity to engage in projects and efforts focused on improving the quality and security for today and our future. Intel remains committed to providing contributions that benefit open source software supply chains and improving the security posture of critical projects on which our ecosystem depends.”
JPMorgan Chase
“JPMorgan Chase is deeply committed to working with the open source community to solve our most pressing security challenges. As a founding member of the Open Source Security Foundation, we have worked together to improve the security of open source and the integrity of all software. We commend the US Government’s recent initiative to raise awareness on this pressing topic and call to action the technology community to solve one of the most complex security challenges of our time. We welcome the new members to OpenSSF and look forward to continuing the journey of innovation and bringing meaningful change to how we build, secure, and validate software,” said Pat Opet, Chief Information Security Officer, JPMorgan Chase & Co.
Microsoft
“As open source is now core to nearly every company’s technology strategy, securing open source software is an essential part of securing the supply chain for every company, including our own. All of us at Microsoft are excited to participate with others in contributing new investments to the Open Source Security Foundation and we look forward to building more secure software through community-driven efforts to create solutions that will help us all,” said Mark Russinovich, Azure CTO and Technical Fellow, Microsoft.
Morgan Stanley
“Whether we are leveraging open source in our own code, contribute to OSS projects, or consume OSS via technology we procure and utilize, the safety and security of OSS and the creation of a trustworthy supply chain is critical to all businesses. To that end, we are delighted to join the Linux Foundation’s Open Source Security Foundation project to collaborate with our cross-industry partners to improve the security, safety and trust in the OSS ecosystem,” said Neil Allen, Global Head of Cyber Security Engineering, Morgan Stanley.
Oracle
“As a contributing member of the open source software community and an inaugural Linux Foundation member, Oracle has a large number of developers that contribute to third-party open source projects daily,” said Wim Coekaerts, senior vice president of software development, Oracle. “Oracle looks forward to participating in the Open Source Security Foundation and working with other members to continue to strengthen the software supply chain, helping customer work more securely.”
Red Hat
“Open source is pervasive in software solutions of all kinds, and cybersecurity attack rates are on the rise. Our customers look to Red Hat to provide trust and enhanced security in our open source based portfolio. Open source and community collaboration is the best way to solve big, industry-wide challenges, such as open source supply chain security. And that’s why we’re excited to join together with the Linux Foundation and other industry leaders so we can continue to improve the technologies and practices to build a more secure future from open source software,” said Chris Wright, senior vice president and CTO, Red Hat.
Snyk
“Open source is built by millions of empowered developers, who also need to secure this critical foundation of the digital world,” said Guy Podjarny, Founder & President, Snyk. “The vital work of the Linux Foundation and the OpenSSF ensures we collectively live up to this responsibility. The Snyk community is fully committed to this important, collaborative effort and we look forward to working closely with the other OpenSSF members to better secure OSS so it can continue to safely fuel innovation.”
VMware
“Every company that uses software should be concerned about their software supply chain,” said Kit Colbert, chief technology officer, VMware. “For two-plus years, VMware has engaged in contributions to open source projects in the broader software supply chain security space and invested in initiatives to help customers further strengthen their security policies and processes. As a member of the Open Source Security Foundation, we’re committed to collaborating across the industry to drive increased level of software supply chain security.”
Apiiro
“Software supply chain risks are becoming pervasive, with the potential to slow application delivery and stunt innovation,” commented John Leon, VP of Business Development at Apiiro. “Managing application risk has become increasingly complex and requires visibility across the SDLC – including the supply chain. Apiiro is excited to partner with the open source community and support the Linux Foundation and OpenSSF as they power the collaboration that is vital to securing software.”
AuriStor
“AuriStor’s founders have contributed to the standardization of security protocols and open source development of security first software for more than 35 years. We view the OpenSSF, its working groups and projects, and those that participate in them as crucial to improving the security of every industry, service, and home. The OpenSSF has the potential to make a significant difference in everyone’s future. We encourage all members of the software development community to contribute,” said AuriStor Founder and CEO Jeffrey Altman.
Devgistics
“We seized the opportunity to join this foundation because OpenSSF offers a real industry-neutral forum to accelerate the hardening and security of the software supply chain. Devgistics (formerly InfoSiftr) provides critical enhancements to the world’s most popular open-source repository. Devgistics has been involved in many free and open-source initiatives for years, including being a Moby (Docker Engine) maintainer, providing support to the Docker/container ecosystem, and serving in the Open Container Initiative. Devgistics continues to contribute cutting-edge solutions for security-conscious clients like the US Air Force,” said Devgistics Founder and President Justin Steele.
DTCC
“DTCC is committed to developing highly resilient and secure code to safeguard the financial marketplace. DTCC is proud to be part of the OpenSSF community and looks forward to partnering with our fellow members on safe, secure and reliable computing,” said Ajoy Kumar, Head of Tech/Cyber Risk at DTCC.
GitLab
“As organizations modernize software development and shift security left, GitLab believes that open source will play a key role in fostering this modernization and delivering secure software with speed to the market,” said Eric Johnson, CTO at GitLab. “Supporting the Open Source Security Foundation aligns with GitLab’s mission of enabling everyone to contribute, and we look forward to supporting, collaborating, and sharing our expertise in implementing security in GitLab’s DevOps Platform to the OpenSSF community.”
Goldman Sachs
“Continuing to secure the software supply chain, in particular the many critical open source projects foundational to any modern organization’s IT architecture, is a top strategic imperative for Goldman Sachs, our peers, partners, and clients in financial services, the technology ecosystem, and the wider economy,” said Atte Lahtiranta, chief technology officer at Goldman Sachs. “This work cannot be done in individual organizational silos. We instead need to work collaboratively, across both the private and public sector, together with open source maintainers and contributors, to answer the call to action that is the recent cybersecurity executive order. The OpenSSF will provide an essential forum and associated infrastructure to allow us to share leading practices, develop improved tooling, and work together to better protect our digital infrastructure.”
JFrog
“Open-source software is the backbone of hundreds of thousands of today’s applications, making it critical that we do our best to flag new vulnerabilities and insecure components fast—before they compromise businesses or critical infrastructure,” said Asaf Karas, JFrog Security CTO. “We’re happy to expand our membership with the Linux Foundation and support this cross-industry collaboration to identify and fix open source security vulnerabilities, strengthen tools, and promote best practices to ensure developers can easily shift left and bake-in security from the start of application planning and design — all the way to software deployment, distribution, and runtime.”
StackHawk
“Software development is moving faster than ever before. The industry needs tooling and processes to ensure that security can keep up with today’s pace of development. StackHawk is excited about the work that the Open Source Security Foundation is doing to improve security and we are proud to continue as a member,” said Joni Klippert, StackHawk Founder & CEO.
Tencent
“IT development to date, an increasing number of critical businesses and core competencies have been built on open source, and this trend will continue. As an important part of the software supply chain, open source security plays an important role in the entire software supply chain. Tencent Cloud has always been keen to contribute code and technology to open source projects, and also maintains a continuous huge investment in security. It is very gratifying to see that OpenSSF can be established, and we look forward to working closely with industry partners to improve the security level of open source software and strengthen the software supply chain security,” said KK Dong, Chief Security Officer at Tencent Cloud.
Wind River
“As the dependency on open-source software becomes increasingly pervasive, the Open Source Security Foundation’s community-driven approach to developing and sharing security metrics, tools and best practices becomes an imperative. Our customers are actively interested in the health of the open source from which their solutions are constructed, and assuring secure development across open the supply chain is vital,” said Paul Miller, CTO, Wind River. “We are looking forward to collaborating more closely with the OpenSSF community. By working together, Wind River can provide customers with a level of open source security assurance that would otherwise be unobtainable.”
Founded in 2000, the Linux Foundation is supported by more than 1,800 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure, including Linux, Kubernetes, Node.js, Hyperledger, RISC-V, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at https://www.linuxfoundation.org/
###
The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.
Jennifer Cloer
503-867-2304
jennifer@storychangesculture.com
The post Open Source Security Foundation Raises $10 Million in New Commitments to Secure Software Supply Chains appeared first on Linux Foundation.
An update on recent improvements to memoptimizer, and how it avoids unnecessary invocation of the Out of Memory killer.
Click to Read More at Oracle Linux Kernel Development
Learn how to use a collection of supported Ansible roles and modules for managing RHEL.
Read More at Enable Sysadmin
New Podman secrets features allow users to fine-tune their secrets settings to their liking.
Read More at Enable Sysadmin