devopsy.kinsta.cloud

Tag: jfrog

  • JFrog swampUP: Keynotes and What’s Next

    JFrog swampUP: Keynotes and What’s Next

    At the sold-out JFrog swampUP conference this morning, the event’s keynotes were headlined by JFrog CEO Shlomi Ben Haim and co-founder and CTO Yoav Landman. The theme was “next”—what’s next for DevOps and what’s next for developers.

    Of course, there are several answers, but cutting to the chase, it seems security is job one. Developers are squarely in the crosshairs of the bad guys, and protecting them and their code is top priority at JFrog. To do so requires shifting security even further left into the integrated development environment (IDE) itself. Landman demonstrated new functionality in the JFrog Xray scanning and remediation solution’s IDE and emphasized the difference between quality assurance and quality testing.

    CEO Ben Haim took a higher-level view, looking at the issues facing organizations as they seek to develop more, develop faster and do so more securely. He also reinforced the themes hit on by Landman. Overall, the message from both co-founders was that the amount of code being deployed continues to increase exponentially. The need to go faster while being more secure is greater than ever, and JFrog has adopted that as the company’s mission, Ben Haim and Landman said.

    Audience enthusiasm was high, and despite growing to almost 1,000 employees, many of whom have been on board for less than a year, the culture at JFrog remains a constant focus. Landman and Ben Haim reiterated that the company is committed to their customers and their community. 

    That community was well represented, with all three of the major cloud providers exhibiting in the expo area, as well as a good mix of other DevOps providers like CloudBees (whose own DevOps World Roadshow kicked off today). Additionally, some of the new channel partners, such as IT Methods, also exhibited.

    Beyond the keynote, other JFrog presenters in the morning keynote sessions included the leadership of the Artifactory team and senior leadership of the security team.

    JFrog leaders were not the only ones on the agenda at swampUP. A leading games company presented a demonstration of their use of JFrog for CI/CD pipelines. One of the big three cloud providers presented a session discussing whether AI will replace developers (spoiler alert: The answer is no). Additionally, frequent devopsy.kinsta.cloud contributors Tracy Ragan and John Willis also presented throughout the day. Our own Will Willis will be recapping some of those highlights.

    All in all, it was a return to normalcy for swampUP. This event felt much like previous swampUPs that occurred before  the COVID-19 pandemic began. The event was sold out with over 400 attendees, which tracks with what we’ve seen at other in-person events recently.

    JFrog has grown and matured but continues to emphasize what has made the company successful. We’re excited to see lots of new features for developers and DevOps practitioners to explore.

  • JFrog Launches New Channel Partner Program

    JFrog Launches New Channel Partner Program

    At JFrog’s swampUP event in San Jose, California, the company launched its Global Channel Partner Program. The program, led by Kelly Hartman, VP of alliances and partners, is JFrog’s first formal program to work with the channel to bring its DevOps and DevSecOps solutions to market.

    Rather than the traditional pyramid model, Hartman, who was formerly at AWS, has designed a flatter program; partners can choose to work with JFrog in a co-selling arrangement, as a traditional reseller or as part of JFrog’s government sales partners. Partners can choose which type of relationship they want to use on a case-by-case, deal-by-deal basis. This gives them lots of flexibility.

    This program is a sign of JFrog’s continuing evolution from a startup to a public company. Several of the founding channel partners in the program weren’t surprised at the announcement; the feeling was, as Mike King of IT Methods said, “They have been knocking on this door for some time.” Hartman added that the goal was not to make JFrog a 100%-channel company. Rather, the aim is to have as much business run through the partners as JFrog’s customers want while keeping the emphasis on the JFrog customer base.

    The program is primarily aimed at DevOps consultants worldwide, rather than the larger integrators, JFrog said. The DevOps consultant market is broadly fragmented, and made up of numerous sized companies – from one to two-person operations all the way up to 1,000+-person organizations, such as IT Methods.

    Hartman said she is learning from her past experience at AWS and other organizations. She has not crafted a traditional program with tiers and marketing development funds; instead, much of what partners need is built into a self-service portal, including a campaign in a box and social media kits.

    IT Methods is an ideal partner for JFrog, King said. They offer a fully-managed SaaS, single-tenant platform allowing their customers to manage their DevOps environments. IT Methods supports more than 45 DevOps tools and its major clients are large enterprises. They have offered JFrog via their platform for six years, but welcome the formal partner program and accompanying certification offered for SMEs. King said he was pleasantly surprised at the JFrog program’s maturity, considering it is a new program. He added that joint lead generation and closing capability and partner enablement offerings would put JFrog “at the head of the class.”

    The JFrog channel partner program joins their existing technology partner and cloud partner programs. In fact, Hartman said they are working with their cloud provider partners to source new channel partners. 

    It was an exciting new development in what promises to be a gangbuster swampUP here in San Jose. More developments will follow.

  • JFrog Extends DevOps Reach to Manage and Secure AI Models

    JFrog Extends DevOps Reach to Manage and Secure AI Models

    At its swampUP 2023 conference, JFrog today added additional security capabilities to its continuous integration/continuous development (CI/CD) environment as well as making it possible to manage machine learning models within the context of a DevOps workflow.

    The latest edition of the JFrog Software Supply Chain Platform adds an integrated static application security testing tool (SAST) to scan source code alongside the existing JFrog Xray tool for scanning binaries.

    JFrog has also added an Open-Source Software (OSS) Catalog to the JFrog Curation service to make it simpler for DevOps teams to discover specific packages that have been determined to be secure. JFrog is also adding Release Lifecycle Management (RLM) capabilities that enable aggregating software artifacts into an immutable software package that serves as the single source of truth as multiple iterations of an application are developed. JFrog RLM uses anti-tampering systems, compliance checks and evidence capture to collect data and insights to ensure the immutability of signed binaries.

    Finally, ML Model Management capabilities, available in beta, are being added to the platform to make it possible to store AI models, run AI models from Hugging Face, a provider of open source AI models, as a proxy in cache via an application programming interface (API) and apply DevSecOps best practices to govern, secure and ensure licensing compliance.

    JFrog CTO Yoav Landman said that as DevOps teams become more familiar with AI models, it’s becoming increasingly clear they are managed like any other software artifact incorporated into a DevOps pipeline. He noted that the approach provides the added benefit of helping to ensure AI models have not been poisoned by malicious data and prompts that would deliberately cause a hallucination.

    Most AI models today are created by data scientists using machine learning operations (MLOps) best practices that each organization defines. In some instances, those processes include what is known as a feature store that enables data scientists to track which components are being used at any given time. However, once a model is completed, it needs to be integrated into an application—a process that, from a DevOps perspective, is best facilitated by storing an AI model in a Git repository alongside other components that need to be managed.

    It’s still early days as far as the convergence of DevOps and MLOps practices are concerned. Going forward, as it becomes apparent almost every application will be invoke some type of AI model, the need to integrate these workflows is becoming a more pressing concern.

    It’s now only a matter of time before AI models become a pervasive element of the software development life cycle as they are continuously retrained and updated. It will generally fall to DevOps teams to manage the deployment and updating of those AI models in collaboration with the data science teams that train them. The immediate challenge, of course, will be to bridge the significant cultural divide between two very different types of IT professionals.

  • JFrog’s swampUP 2023: Ready for Next 

    JFrog’s swampUP 2023: Ready for Next 

    In the ever-changing landscape of technology and software development, staying ahead is essential. JFrog has led a pioneering effort to transform DevSecOps since its founding in 2008. Micheline Nijmeh has been chief marketing officer for the past three years, and in that time, she said JFrog has steadily tackled critical issues across the industry.

    “JFrog really started off addressing a pain point, which involved being a software supply chain platform that simplifies the DevSecOps processes by automating the entire software build and release process for large enterprises,” Nijmeh said. 

    On Sept. 13, JFrog will host its marquee event: swampUP. For those anticipating this year’s event, this is more than just a conference. The people heading to San Jose, California, are dedicated to advancing the DevSecOps landscape, and the event is designed to foster a holistic environment for collaboration and learning, Nijmeh said.

    “It really brings everyone together. Whether you’re a DevOps practitioner, security practitioner, as well as leaders and managers, all in one place,” Nijmeh said. 

    Image from swampUP 2022 courtesy of JFrog

    This year’s theme, “Ready for Next,” captures JFrog’s dedication to continuous growth, she added. Nijmeh explained that organizations are always evolving and transforming, and that they need a partner that can grow with them.

    Among the numerous topics that will be discussed at JFrog’s ninth swampUP event is security and DevSecOps, Nijmeh said, adding that “security is top of mind as always.” 

    Several keynote speakers will focus on security, including Bruce Schneier, a security guru and New York Times best-selling author of 14 books.  

    And although security will always be a hot topic, DevOps is expected to generate buzz as well. 

    “We have John Willis, who’s known as the godfather of DevOps. We’re also having folks from Riot Games, Fidelity, Netflix, CapitalOne and others representing their use cases on how they are addressing not just DevOps, but DevSecOps, in some cases,” Nijmeh said. 

    With a star-studded roster of speakers, expectations are sky-high. Furthermore, Nijmeh explained that the show has continued to evolve and has grown to be much more comprehensive. 

    “It’s not just about DevOps, it’s [also] about security. All the way from the left to the right. From development to deployment,” Nijmeh said. 

    For attendees, JFrog has placed focus on actionable insights, as it aims to provide information and tools that can actually be implemented within their organizations right away. SwampUP aims to provide attendees with practical know-how. Although the goal is to be ‘ready for next,’ it’s vital that practitioners and leaders understand what they can do today as well. 

    “Anything that we announce at swampUP will be available to our customers,” Nijmeh said. We’ll be sharing some partner announcements and some new innovations that no one has ever seen before.”

    Image from swampUP 2022 courtesy of JFrog

  • JFrog Adds Curation Capability for Open Source Software Components

    JFrog Adds Curation Capability for Open Source Software Components

    JFrog today announced it is adding a curation capability for open source software to its portfolio that will use metadata generated by binaries to identify malicious packages and software components that have licensing issues.

    Sharan Hiremath, senior product manager for JFrog, said JFrog Curation is an extension of the JFrog Artifactory binary repository that the company provides to enable organizations to manage their software supply chains.

    JFrog Curation also validates software packages against JFrog’s Security Research library of recorded Critical Vulnerabilities and Exposures (CVEs) and publicly available information to help establish a trusted repository of pre-approved, third-party software components.

    That approach automatically employs the JFrog Xray scanning tool to eliminate the need to individually scan each package before developers employ them, said Hiremath.

    Making sure open source software components are secure is often problematic because developers download them from public repositories that are frequently targeted by cybercriminals. There have now been more than 100,000 instances of malicious software packages discovered in repositories in the last year alone, noted Hiremath.

    In addition, cybercriminals have become adept at creating fake repositories that mimic legitimate repositories; that can result in developers downloading software components infected with malware.

    JFrog Curation takes the shift left concept of application security to the next level by automatically blocking the use of risky open source software packages, noted Hiremath. The JFrog platform will also surface advice on how to remediate any vulnerability discovered, in addition to creating an audit trail to enable organizations to comply with various regulatory mandates.

    While open source software components reduce the cost of application development, from a cybersecurity perspective, it’s the wild, wild West, noted Hiremath. Organizations are trying to bring more discipline to the way software is constructed by adopting DevSecOps best practices, but they need an approach that doesn’t introduce any additional friction into the application development process, he added.

    JFrog Curation addresses that issue by addressing cybersecurity and compliance issues before any open source component becomes part of the build, said Hiremath.

    As regulations to hold organizations more accountable for the security of the software they deploy are being proposed around the world, it’s only a matter of time before organizations must revisit the security of their software supply chains. Cybercriminals have already proven how adept they are at injecting malware into software components that could be used in thousands of downstream applications. In the eyes of regulators, organizations that don’t scan open source software for malware and vulnerabilities are engaging in reckless behavior that will warrant stiff penalties.

    The challenge is that, after giving developers free rein to develop software any way they see fit, organizations are now faced with a challenge that is as much cultural as it is technical. Automated processes will naturally play a key role in curbing aberrant behavior in application development, but there is, as always, no substitute for some good old-fashioned common sense.

  • DORA Report 2022: The Magnitude of Software Supply Chain Security  

    DORA Report 2022: The Magnitude of Software Supply Chain Security  

    The term ‘software supply chain security’ (SSC) can be interpreted in many ways. Following the White House executive order in May 2021 and the European Cyber Resilience Act (CRA) of 2022, both governments and corporations are taking a more active role in ensuring their software is secure. Fundamentals such as having a software bill of materials (SBOM) and being able to cross-reference it with known common vulnerabilities and exposures (CVEs) are now the standard, but supply chain security covers far more than just the software that builds your products.

    To create certainty and clarity, leading standardization bodies such as OWASP, OpenSSF and others have set up ongoing efforts to define and mitigate SSC threats. They have active working groups, SIGs and TACs all working in vendor-neutral ways to help define and solve parts of the SSC problem.

    A great example of this is the continuous work being done by Google Cloud’s DevOps Research and Assessment (DORA) initiative. More specifically, the subject was reflected in the September 2022 DORA report that focused on security in general and supply chain security in particular. Using the Supply-chain Levels for Secure Artifacts (SLSA) framework as well as the NIST’s Secure Software Development Framework (SSDF) as benchmarks for actively addressing supply chain security issues, the researchers assessed how organizations were successful in approaching and addressing threats at all levels of the organization.

    My view of the major findings of the DORA report are summarized below.

    Who Owns Software Supply Chain Security?

    The report stated that organizations should empower individual teams and developers to “own” security while administering a consistent security policy and posture across its products. While I agree with this, we need to examine both sides of the ‘ownership’ coin. By nature, this hybrid approach creates complexity—and even friction—between the security team that, by definition, is responsible for all facets of security and the developers that are being tasked to ‘fix’ security issues in addition to their daily tasks. There has to be common ground between developers, their tasks associated with security and the security team.

    Individuals in organizations that build software care about what they build; they have a stake in the overall success of the final product and this feeling of ownership strengthens that level of care. However, asking for such ownership while adding a security component to the mix without providing sufficient knowledge, tools, proofs, and “power” to make decisions could lead to  a lack of trust, confusion, execution problems and frustration. To alleviate this, the security team should provide developers the tools, education and resources they need to feel empowered to enhance security efforts at the source. Organizations that provide evidence in a scalable, digestible manner are successful in building trust and creating common ground between the developer, security and the security team.

    There’s also another dimension that could potentially create silos between developers and security teams rather than bringing the two together: There’s no one single security team or owner of SSC. SSC is tricky to define as a category; it involves shift left security, runtime security and everything in between. Some portions of it are being governed by the security office, some by AppSec, some by DevOps and some by the developer. The ownership of each isn’t well-defined and the entire effort is very difficult to consolidate as one process or methodology. In addition to upskilling the developer with tools and training, long-term education, thought leadership and access to good technology are the keys to gradually reduce these friction points..

    Security Processes Slow Down Development

    Defining the tools, methodologies and processes that should be employed in an organization to add sufficient security while not impacting development speed is not a trivial task.

    ­­The following are four principals I think correspond well with the SLSA framework and that help address the development slowdown challenge:

    Set preventive measures: Avoid using known vulnerable and malicious packages from the beginning of development. By eliminating vulnerabilities introduced in first-party code (due to bad coding practices) as well as misconfigurations, wrong encryption and secrets exposures, you are preventing known threats from entering your product.

    Examine proactively and continuously: The security state of software changes because the software itself always evolves and new vulnerabilities are continuously being introduced. It makes a software artifact that was just secured suddenly become susceptible to attack. This requires continuously rescanning and revisiting software artifacts as well as frequently recalculating any potential risk.

    Set preemptive measures: Create a plan that initiates a prompt response when a potential risk is discovered. Both development and security teams should create the plan for decision making and execution. The measures should include ways to identify vulnerable artifacts across development and production, how to understand exploitability and true impact and how to prioritize and remediate accordingly.

    Do it all in an automated manner: Create automated processes based on reliable data and scanning tools to dramatically reduce the effort needed by developers and DevOps teams.

    DORA report co-author Eric Maxwell said one of the main principles is to remain tool- and platform-agnostic while focusing on capabilities and practices. From that perspective, automation is essential and it is enabled by security-as-code. Having a common language–code–allows teams to communicate about security as well as collaborate. It drives the things we discussed earlier around democratizing the security process and helps break down silos.

    The DORA findings—alongside the topics described above—encourage community awareness and continued shared efforts to bring much-needed attention to software supply chain security. Gradually, SSC security will evolve, but as it does so, the only way to properly address it is by ensuring the developers and security teams are on the same page and both have ownership of responding to and resolving issues as they appear. For more in depth review of the DORA report I encourage you to view Leap Left for Security: The DORA Report Roundtable.

  • JFrog Aligns With New Relic to Improve Observability

    JFrog Aligns With New Relic to Improve Observability

    JFrog and New Relic jointly announced today they will provide a free integration tool that will enable New Relic’s observability platform to consume log data from JFrog platforms for building and deploying applications securely.

    Announced at the Futurestack conference hosted by New Relic, this integration eliminates the manual effort that was previously required to integrate these platforms. Preconfigured New Relic dashboards provide a comprehensive view of performance data, artifact usage and security metrics in real-time that is automatically collected from JFrog Artifactory and JFrog Xray environments and then displayed alongside other telemetry data.

    Omer Cohen, executive vice president of strategy at JFrog, said that capability will make it easier to identify performance issues, urgent vulnerabilities and malicious users in a way that reduces the amount of time required to remediate those issues across the software supply chain.

    The goal now is to eventually provide similar levels of integration between JFrog platforms that enable DevOps teams to manage and secure application binaries with other observability platforms, added Cohen.

    It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex the plethora of monitoring tools that DevOps teams rely on need to be augmented. Observability platforms promise to unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue. The rate at which DevOps teams will embrace observability will naturally vary, but the biggest obstacle might not be the platforms themselves. The biggest challenge is understanding which queries to actually launch to identify an issue that might later cause a major disruption. In the longer term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify those issues. In the meantime, much still depends on the acumen of the DevOps team employing an observability platform.

    In fact, a recent New Relic survey found only 27% of respondents have achieved full-stack observability, with only 5% claiming they have a mature observability practice in place. A third (33%) of respondents also said they still primarily detect outages manually or based on complaints, the survey found. More than half (52%) of respondents also admitted they experienced high-business-impact outages once per week or more and 29% said they take more than an hour to resolve those outages.

    On the plus side, nearly three-quarters (72%) expected to maintain or increase their observability budgets next year. More than half (52%) of respondents, including 57% of C-suite executives, expected observability budgets to increase over the next year. A total of 14% of all respondents and 16% of IT decision-makers expected to increase observability budgets significantly or extensively. More than a third (36%) believe observability increases their productivity and enables them to find and resolve issues faster. Just under a third (32%) said observability enables cross-team collaboration, while more than a quarter said observability improves their ability to innovate.

    One way or another, visibility into DevOps environments clearly needs to improve as application environments become more complex. The challenge, as always, is determining the cost required to achieve it.

  • JFrog Gives Pyrsia to CD Foundation to Secure Software Supply Chains

    JFrog Gives Pyrsia to CD Foundation to Secure Software Supply Chains

    At the KubeCon + CloudNativeCon North America conference this week, JFrog announced it contributed the Pyrsia project, which uses blockchain technologies to secure software packages, to the Continuous Delivery (CD) Foundation.

    Stephen Chin, vice president of developer relations at JFrog and governing board member for the CD Foundation, said the goal is to increase the number of contributors to the project. Current contributors to the Pyrsia project include Docker, Inc., DeployHub, Futurewei and Oracle.

    As part of those efforts, the CD Foundation will bring a centralized governance model through which a roadmap for the project will be defined.

    Pyrsia provides IT teams with a decentralized blockchain network to access an immutable software package repository that is designed to seamlessly integrate with the package management systems developers already employ. It creates a digitally signed, immutable chain of evidence for code that can be incorporated into a software bill of materials.

    Securing software supply chains became a more urgent issue following the discovery last year of the zero-day Log4Shell vulnerability that impacted Java applications. Many developers routinely reuse open source software, but many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited; the onus for making sure that software is secure falls on the organizations that decide to deploy it.

    The trouble is, many organizations that rely on open source software assume it is more secure than it really is. Initiatives like Project Pyrsia are part of a larger effort to make it simpler for maintainers to secure open source software.

    It’s not clear to what degree security concerns are prompting organizations to review the amount of open source software they consume. Most organizations are more dependent on open source software than they realize, as most packaged applications include a large amount of open source code that is downloaded from any number of repositories. Whenever a zero-day vulnerability is discovered, organizations can easily spend months looking for all the instances of an open source component that might be vulnerable.

    In theory, blockchain platforms and DevSecOps best practices should make it easier to secure software packages by reducing the number of vulnerabilities in production environments. The challenge organizations face today is the amount of technical security debt that exists due to vulnerabilities in legacy applications. It might be close to a decade before applications based on more secure code replace existing solutions.

    In the meantime, multiple approaches to securing software supply chains are advancing, including the use of some type of immutable platform. It may be a while before those platforms are widely incorporated into software supply chains, but it’s apparent that it’s now more a question of how long it will take rather than if those technologies will be applied to securing software development environments.

  • JFrog Adds Module to Better Secure Software Supply Chains

    JFrog Adds Module to Better Secure Software Supply Chains

    JFrog today added a JFrog Advanced Security module to its Artifactory repository that enables DevOps teams to scan both binaries and source code for vulnerabilities and misconfigurations.

    Stephen Chin, vice president of developer relations for JFrog, said that approach will enable DevOps team to ensure applications are secure before they are deployed in a production environment.

    In addition to discovering vulnerabilities, the JFrog Advanced Security module also detects exposed secrets such as passwords, access tokens and private keys, said Chin. Leveraging existing scanning capabilities provided via the JFrog Xray software composition analysis tool, it can also be used to inspect the file used to provision infrastructure-as-code, he added.

    Most importantly, it provides development teams with the context needed to determine which components of an application are using containers that encapsulate code that is actually exploitable, noted Chin.

    One of the major issues DevOps teams encounter today is that they are often presented with a long list of vulnerabilities by cybersecurity teams—many of which don’t meaningfully impact applications that are not exposed to the Internet. DevOps teams then need to manually report why any given vulnerability doesn’t need to be remediated. The JFrog Advanced Security module helps automate that process, said Chin.

    In general, JFrog continues to pursue a binary-first approach to securing software supply chains, said Chin. While it’s important to address vulnerabilities in source code whenever possible, it is application binaries running in a production environment that cybercriminals are going to exploit, he noted.

    Cybercriminals have, in effect, opened a new front in their efforts to compromise IT environments by injecting malware into software components before they are deployed in a production environment. The hope is that, once deployed in those environments, malware can be activated at some later date. As a result, DevOps teams are now being required to improve cybersecurity hygiene across their software development processes, said Chin.

    It’s not clear at what rate organizations are embracing DevSecOps best practices to achieve that goal, but in the wake of an executive order issued by the Biden administration that requires federal agencies to better secure their software supply chains, the expectation is that more enterprise IT organizations will follow suit. The challenge is finding a way to build and deploy more secure applications without negatively impacting the rate at which they are built and deployed. Earlier this year, JFrog launched the open source Pyrsia project that employs blockchain technology to ensure open source software packages are not compromised by vulnerabilities and malicious code.

    In the longer term, it’s only a matter of time before the historic divide that has existed between DevOps teams and cybersecurity professionals starts to narrow as applications become more secure. The biggest immediate challenge is that many of the applications deployed in production environments already have known vulnerabilities. In the months ahead, many DevOps teams will be asked to assess the severity of those vulnerabilities as part of ongoing efforts to improve application security. Those patching efforts will undoubtedly have a significant impact on the amount of time available to write the code needed to build new applications or update existing ones with new capabilities.

    One way or another, however, the amount of technical security debt that has been allowed to build over the last several decades needs to be addressed.

  • Rust Foundation Allies With OpenSSF and JFrog to Secure Code

    Rust Foundation Allies With OpenSSF and JFrog to Secure Code

    The Rust Foundation announced today it is working with the Open Source Security Foundation (OpenSSF) and JFrog to help maintainers secure open source software created using the Rust programming language.

    Rebecca (Bec) Rumbul, executive director at the Rust Foundation, said even though Rust is a memory-safe language, there are still security issues that maintainers need to be able to address. The goal is to provide the resources those maintainers need to better secure their software supply chains.

    As part of that effort, the Rust Foundation is adding a dedicated security team to help maintainers of open source projects built using Rust to better secure their software supply chains. That team is being underwritten by JFrog and the Alpha-Omega Initiative funded by Google and Microsoft which was recently launched by OpenSSF. JFrog last week announced it is joining the Rust Foundation at the Platinum level alongside Amazon Web Services (AWS), Google, Huawei, Meta, Microsoft and Mozilla.

    The first initiative for the security team will be to conduct a security audit and develop threat modeling tools that will provide the foundation for a set of best security practices for maintainers, said Rumbul. The team will also help advocate for those security practices across the Rust landscape, including the Cargo package manager and Crates.io directory projects.

    The OpenSSF has previously called for replacing programming languages like Java that are not memory-safe as part of a larger plan to secure open source software supply chains.

    In general, the Rust Foundation is committed to enabling Rust developers to achieve their scale, security and sustainability goals, said Rumbul. Given the early stages of the Rust programming language, there is no better time to start addressing security issues that application developers can’t ignore, she added.

    In the longer term, The Rust Foundation is also committed to providing developers with Rust security education and is also working to come up with a fair approach to certifying which projects have achieved an appropriate level of cybersecurity maturity, said Rumbul.

    It’s not clear whether developers are abandoning older programming languages in favor of a memory-safe language such as Rust. Rust employs a compiler to track the ownership of values that can be used once and a borrow checker that manages how data is used without having to rely on traditional garbage collection techniques.

    Of course, replacing trillions of lines of code that have already been constructed using a variety of legacy languages is a gargantuan task that might never be fully completed. However, as new applications are built using a memory-safe programming language, the overall security posture of an organization will steadily improve. The challenge, of course, is that the number of developers that know how to build applications using those languages is still relatively small.

    Nevertheless, there may come a day when the way applications are coded is a lot more secure by default than it is today. In the meantime, however, the number of vulnerabilities that exist with application environments is still too numerous to count.