What were the trends for DevOps tools and culture in 2022? I talked to Aisling Conroy, Senior Manager of Competitive Intelligence at CircleCI and Luke Kilpatrick Director of Developer Experience at LinearB, to review the year and discuss key learnings and trends at our December webinar.

In 2022 did we get any better at developing software?
- Did we make any headway at automating human frailty out of building software?
- Did AI make a difference in building software?
- Does the focus on multi-cloud mean the death of on-prem?
- How healthy is open source after the big shock of Log4Shell?

2022 started with a huge amount of ambition from tech companies which did so well during the pandemic. As the year went on, the belt tightened, and so did plans; as Aisling put it, "everyone has a plan until you get punched in the face." She notes although the grand plans may not have been executed, we got a lot done, but there is still much more to do.

Some of the 2022 trends Luke and Aisling identified included:

Platform Engineering dedicated to improving workflow

AI tools to augment the software developer

I'm going to sum up 2022 DevOps as "the year of the workflow", where we have dedicated people and tools focused on fixing and improving workflows.

Both Linear B and CircleCI are trying to speed up developer workflow.

Aisling tells us that at CircleCI, they want an optimal-size pipeline run of around 10 mins. She sees pipelines on the CircleCI platform become more advanced as customers build more advanced applications than ever, but in some cases, software delivery cycle times have stagnated. "Teams have gone from once a quarter to once a month, which is great, but ideally, we want teams to be able to move at the speed of their creativity."

To improve speed, Aisling tells us there is a focus on tooling, better integrations, interoperability, and spending less time on the manual stuff to become more efficient.

Luke notes that LinearB's customers tend to do a great job of optimizing the ops pipeline but if there is a problem, there are still humans involved. At LinearB, they have done a lot of research on the developer team workflow. They have looked at 10's of thousands of code reviews (PR's) and other areas where there were bottlenecks and found a massive bottleneck around code reviews. So they took this information and tried to help fix the problem. This is what lead to gitStream. Like most things in computing, humans are usually the slowest part of the system. If you have an amazing CI/CD system using CircleCI or other tools, your deployment and delivery problems get reduced. There has been a ton of amazing work done here in the past 10 years. However, checking quality and making sure good code is getting merged is still hard to do. The gold standard is still a peer review of the code.

The biggest slowdown is a lot of small changes don't need this review and a lot of the big ones need to get reviewed more. So LinearB made a tool to help, and best of all, it's free!

Dedicated Experts in Workflows- Platform Engineering

Luke notes that the previous years in DevOps have been focused on the ops side, and a lot still is, but we saw a lot of great stuff coming out to help the developer side of the house. There is also a shift to Developer Experience improvement, also called platform engineering. This really became a big thing in 2022.

Luke likened a platform engineer to a sous chef working alongside a high-end chef. Most high-end chefs are only as good as their sous chef.

Having dedicated experts at a senior level reviewing and improving pipelines and workflow is a big trend for 2022.

The panel agreed there was a big focus on identifying and improving flaky tests. CI tools are highlighting and running metrics on your testing suite. Rerunning flaky tests or turning them off is not good enough. Companies are expected to do more with less, and robust test suites are an avenue for this.

AI tooling for software development is having a moment- from GitHub's CoPilot, CircleCI acquisition of Ponicode to the recent surprise of ChatGPT, which forced StackOverflow to ban answers from the AI tool.

At the start of the year, Aisling was quite bullish on AI, and she saw it being used to help developers.

She notes that this is an example where we all got very excited at the start of 2022, and we all thought we'd be living in a different world by the end of the year. We've seen many companies make efforts in the AI area over the past year, and it's been good progress, but actual progress has not come close to where we anticipated it to be.

But as we see AI tooling moving to where we write code, like CoPilot and Ponicode, it is bound to change how we develop software in the coming years.

Boring Programming Languages are making waves

I love comparing languages- the loyalty people feel towards their chosen programming language and the ecosystems it creates are the closest software comes to football.

y on the best and worst programming Languages for developer workflow. LinearB's metric dashboard has used its data on thousands of dev teams and hundreds of thousands of pull requests to see how languages compare with respect to PR lifespans.

It turns out, that Java and C# have a significantly shorter PR lifespan compared to other languages.

Luke tells us that Java and C# are more mature languages that have great tooling integrated into their workflows.

This year the discussion around hybrid cloud has shifted to multicloud. I wondered if this meant that on-prem is just yesterday's news - case closed?

Both Luke and Aisling disagreed!

Aisling says that there is always going to be some users that will need on-prem, maybe in niche industries like mining, aerospace etc. The trend has been steady in 2022 and will continue in 2023. MultiCloud will continue to gain more traction. In fact, Google had this as a prediction in their GoogleNext conference in September. There is talk of US legislation specifying that large corporations must follow a multi-cloud strategy. But there are still certain types of computing that customers might want to have in-house. Apple M1 is an example of this, though I think we'll see a lot of progress in the coming year in cloud companies being able to provide a growing variety of configurable compute options.

Luke, as a former Nutanix guy, believes on-prem will always have its place, but cloud tech will be part of it and moving loads from on-prem to public will become easier and faster. The tools for doing this are getting better. At the moment for large organizations, on-prem tends to be cheaper in the long run. Luke sees companies using a burst model where you can use infrastructure out to the cloud for big bursts of traffic.

MultiCloud strategy is definitely a 2022 trend, but it hasn't killed off on-prem just yet.

2022 started with teams scrambling to find out if they were affected by the 

 vulnerability found in a commonly used open source package called Log4J. It has become clear to most teams this year how dependent they are on open source software and that to truly secure software supply chains, a coordinated effort is needed from the whole software community.

For me, 2022 was the year where tooling began to help teams see what open source software is being used in their products and to help secure software supply chains. Open source tools like Sigstore, Grype, Trivy and Syft have made big waves this year.

Security by obscurity is thought less of:

GitStream is currently being giving it away from free

If you Open Source something, you better reach a certain standard

Aisling saw a trend in open source to improve interoperability in open source tools with Open Policy Agent tools. She was also impressed with how many open source software delivery tools matured, including Argon and Flux. Both Luke and Aisling see open source in a much healthier place at the end of 2022.

Concentration on workflows from a tooling and human level, appreciation of open source and glimmers of what AI can do to improve software development.

Join us on January 31st for our next webinar, which will continue the State of DevOps discussion - A Look Ahead at 2023. Registration information is coming soon.

Recap: 2022 State of DevOps Webinar

The root cause of many vulnerabilities is memory corruption from software written in memory-unsafe languages like C and C++.

The responsibility to stop memory corruption errors is left to the developer in C and C++ and they are often hard to catch. You fix up one memory vulnerability and another one appears.

We can eliminate these vulnerabilities by moving software away from C and C++.

 advise and encourage organizations to move away from memory unsafe languages.

OpenSSL, a crucial C software library found in Linux that implements the TLS protocol, is a good case study in memory vulnerabilities. It has suffered from a number of vulnerabilities due to memory corruption, including:

, found in 2014, allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL.

The NSA recommends C#, Rust, Go, Java, Ruby and Swift as possible alternatives to C and C++.

An important feature of all the memory-safe languages that the NSA recommends is that they have a package manager. Cloudsmith's cloud-native artifact repository supports over 28 different types of languages including 

 to help you with the transition to a memory-safe language.

Memory-safe languages- who is the obvious successor to C and C++?

How do we transition Legacy systems from C and C++?

In C and C++ the memory is allocated to all the variables of a program automatically during compile time. The stack is used for static memory allocation like local variables. Dynamic memory is allocated during runtime on the heap when the size of the memory is not known e.g reading in data. C and C++ developers need to manage their dynamic memory by allocating, deallocating memory and checking for potential memory issues.

Managing your memory and assigning data is where memory vulnerabilities can occur.

Buffer overflows are the most common type of memory corruption in C and C++ and are one of the top vulnerabilities used by attackers.

A buffer overflow occurs when you allocate memory of a certain size but the data you put into it is larger than the buffer has room for. This causes the program to write past the end of the buffer or array and corrupt the extra memory. This vulnerability can be triggered under certain circumstances e.g. unexpected user input.

A buffer overflow attack exploits the buffer overflow vulnerability. This attack can lead to the following:

unauthorized memory being accessed in an information leak attack e.g. Heartbleed in OpenSSL,

modify program code in a code corruption or control-flow hijack attack or

Protections in C/C++ without moving to another language

There are a number of things that can reduce the risk of memory corruption in C and C++, including:

Checking that the allocation of memory succeeded.

Dynamically allocate memory rather than statically when you don't know the size needed.

Defensive programming where you always assume the worst by checking any input including return values from functions.

Using managed buffers and strings rather than raw arrays and pointers in C++.

Using safe functions that include buffer overflow protection e.g use 

The C++ Core Guidelines advise against using 

 directly for creating dynamic objects in favor of smart pointers through 

 for reference-counted multiple ownership.

Heap scanning technologies to improve memory safety of C++.

Operating system kernel settings like ASLR and stack canaries.

Why mitigations against memory vulnerabilities aren't enough

Most of the responsibility to stop memory corruption errors is left to the developer in C and C++ and defenses in the compiler/kernel e.g. ASLR, stack canaries, can be circumvented by attackers. If you are lucky, the program will crash during testing, exposing the memory issue, but these bugs can go under the radar only to be found by attackers when they are running.

 that prevent it from improving its memory safety including tech debt and its commitment to backward compatibility.

Memory corruption in C or C++ has gone on for more than 30 years and continues to be one of the top vulnerabilities in real-world exploits. This is what has driven the NSA to encourage organizations to shift to using memory-safe languages.

Languages such as C#, Go, Java, Ruby, Rust and Swift use built-in safety mechanisms that minimize the likelihood of memory corruption vulnerabilities like buffer overflows.

It doesn't mean that there are no security vulnerabilities in programs developed in these languages but it eliminates a whole class of vulnerabilities.

Languages, like Java, C#, Python and Ruby are interpreted languages. The source code is not directly translated by the target machine. Instead, first, the source code is compiled into a virtual language and then it is interpreted by a VM.

Well-written C and C++ code will generally run faster than well-written code in interpreted languages mostly because they are statically-typed languages compiled to machine code.

Go and Rust are both performant open-sourced, compiled languages that are memory-safe alternatives to C/C++.

The garbage collector manages the allocation and release of memory for an application. In garbage-collected languages (e.g. C#, Go, Java, Ruby and Swift) developers don't have to write code to perform memory management tasks.

C and C++ don't use garbage collection for memory management which improves performance at the expense of security and usability.

The Rust language does not perform garbage collection and instead uses a 

. This allows it to be more efficient and performant than other memory-safe languages but at the expense of usability.

Who is C/C++'s successor? Is it all about speed?

Speed isn't the be-all and end-all in programming.

Optimizations in interpreted languages, powerful chips, cheap infrastructure and the development of performant languages have reduced the need for the speed that C and C++ can achieve. Security, usability, team experience and development time are often more important considerations.

Let's hear about some of the contenders for the C/C++ throne:

Java and C# are pretty fast and have made significant speed increases in the last few years. On top of that Java and C# have comprehensive tooling which leads to a 

really impressive developer workflow at 15hrs/16hr

 to merge a PR compared to the average 40hr. The same study showed that C++ programs took on average 140 hrs to merge a PR.

Go is a good all-rounder with speed and ease of use. Go compiles to machine code, has more modern features, simpler syntax, and is easier to write than C/C++.

But if we talking about applications where speed is the priority- Rust is a memory safe language that is 

 but it comes with a steep learning curve.

How do we transition legacy code from C and C++

There are lots of alternatives for developing new software in memory-safe languages but migrating billions of lines of legacy C/C++ code is a huge task.

Google launched a new programming language called 

. It’s an experimental successor to C++. Carbon is not fully memory safe but it has a path toward achieving robust memory safety.

The primary purpose of the Carbon language is to have performance similar to C++, bi-directional interoperability with C++ and migration from existing C++ code.

 using Rust if it is possible to do so. Many large C++ codebases use features incompatible with Rust making the migration process difficult. This is where Carbon makes sense.

A likely path off memory unsafe programs is to find the most problematic and popular C/C++ programs and replace them 1 at a time.

Rust is now in the Linux kernel- this opens up a lot of possibilities for moving off C and C++ code. One possibility is to replace the use of OpenSSL, a C program that implements TLS and SSL protocols, that has suffered from a number of memory vulnerabilities with 

C and C++ lack guardrails around memory which have led to too many exploitable memory vulnerabilities over the last 30 years. These bugs can be completely eliminated by moving to memory safe languages, like the NSA recommendations of, C#, Rust, Go, Java, Ruby and Swift.

Migrating billions of lines of legacy C/C++ code will be a huge task but pathways exist to make this happen. Who knows, maybe the new Carbon language will develop some nice tools for migrating some of this code without much intervention.

The march has already begun- worries about security, less skilled C/C++ engineers, performant alternatives and trends in software development mean there will be less and less C and C++ code in the world over the next decade.

Cloudsmith supports memory-safe languages

Could 2023 be the year of memory safety?

Software development in the banking and finance industry can make you feel like you’re wearing chains. Regulation, compliance, upfront costs, privacy, legacy systems, fear of cyberattacks, and an “if it ain’t broke” approach can lead to a lack of innovation.

Despite these challenges, some technology-forward banks like Capital One, JP Morgan Chase, HSBC, and Wells Fargo have embraced the cloud and introduced DevSecOps and cloud-friendly architectural practices.

This change has been aided by the fact that cloud providers including 

 can now guarantee compliance to banking regulations, and the existence of new cloud-native core banking engines like 

 to help banks move off their legacy systems. This cloud transformation helps banks stay competitive, move away from batch processing towards real-time results, attract engineers, reduce costs and come up with new innovative products.

Part of this cloud transformation means updating the tech stack for developers working in banking- Getting rid of ‘on-prem’ applications and moving to their cloud-native tools.

Cloudsmith is seeing new interest from financial institutes that want to implement a cloud-native SaaS product - they are not demanding on-prem versions of our product anymore. Today, let’s dive into the benefits of cloud-native package management tools for the finance industry.

So what do developers working in banking need from their package management solution? They need to be able to:

In the next few sections, we’ll explore:

The banking industry has been slow to adopt the cloud, and many banks still run their own data centers to process huge workloads. Banks have long understood that using cloud infrastructure has cost-saving benefits but were reluctant to move from their ‘on-prem’ systems due to privacy and regulatory reasons. The distrust in the cloud is waning as the risks are understood, and the technology matures. Much of the push to 

 is driven by business-as-usual culture, upfront costs, and priority.

Banks have conflicting priorities, making it difficult to find the IT time when systems are happily working- but the pandemic gave many organizations space to relook and revive their IT strategies. Several large banks have undergone a cloud transformation during the pandemic, including:

“A key factor causing ‘core to the cloud’ to reach a tipping point is that cloud-native core banking software applications such as Thought Machine, Mambu, and Finxact are reaching a level of maturity where the journey is worth the effort, ”

, a senior industry director for Banking at Accenture. Maintaining data centers and staying ‘on-prem’ is not just a case of staying still but going backwards.

We've covered the many reasons to move to the cloud as a finance organisation below.

Banks need to innovate quickly to meet customers' ever-changing needs. 

 and Fintechs are putting banks under competitive pressure by offering financial products. Staying still is no longer an option to survive.

“Everything is moving to real-time,” Rohan Amin, the chief product officer at Chase. Customers want their services, like their balances, updated immediately in real-time. Cloud computing facilitates moving to real-time as a general model.

Resilience, scalability, and availability

Banks need to have high availability, resiliency, reliability, and scalability to serve the bank customers with minimum downtime. Cloud-native software can quickly re-adjust its resources to meet demand. When volumes spike in financial markets, traders can use extra computing power to analyze price movements and handle bursts of client activity.

A company experiencing rapid growth can use the cloud to expand its infrastructure and computing power. In contrast, the same company using on-prem infrastructure would have to quickly invest in more hardware, software, and Engineers to keep up with rapid growth.

Banks are becoming less wary of the security of the cloud in part because cloud infrastructure providers and services have matured and can now offer controls validated by third-party auditors like ISO, PCI, and SOC, that 

 with privacy and banking regulations.

Cloud has security advantages over on-premise systems that rely on physical servers. A secure system needs a secure building, training, constant security updates, high availability, monitoring, and disaster recovery infrastructure.

Although banking organizations that host their software on-prem take security very seriously, it is expensive and consumes many working hours. Cloud providers are driven to focus on security as their business and reputation depend on providing a robust and secure service. As a result, cloud providers use highly sophisticated security tools and resources beyond the reach of most in-house teams.

Security is a risk when moving to the cloud but by designing a system with security in mind and by incorporating security into your build and deploy process- your system can be more secure than a traditional on-prem system and stay compliant with regulations.

The upfront cost savings of not having loads of servers in a server farm and “doubling up” by maintaining remote locations for disaster recovery—which all banks require—is significant. Cloud software is hosted for you. You don’t have to worry about maintaining your “on-prem” software or infrastructure- no updates, no security patches, no replacing obsolete hardware.

Cloud-native technologies allow businesses to reduce the total cost of ownership for businesses, especially when you factor in the staff costs of maintaining “on-prem,” never mind just the licensing fees.

Devs need a package management solution to handle a distributed workforce giving everyone similar low latency access speeds. Tools that don’t do this can lead to reduced collaboration, developer unhappiness, and lack of confidence in your software process.

Software engineers are hard to come by, COBOL and assembler specialists even more so. Engineers want to work with the latest technologies. Banks need to embrace tooling that takes advantage of the automation and scalability of cloud-native technologies- freeing up your engineering and server resources to build your products.

Migrating to the cloud has helped many banks and financial institutions compete, improve efficiencies, and lower costs. On-premise software cannot compete with cloud-native software in terms of scalability and flexibility.

Cloudsmith is a cloud-native package management tool that makes life simpler for engineers. Don’t worry about infrastructure, patching, upgrades, replications, or scaling. Our cloud-native architecture enabled us to develop a smart CDN for software packages, called the Package Delivery Network (PDN). The PDN is optimized to ensure lightning-fast delivery for deploying or shipping licensed software to your customers.

A package/artifact/image groups together files containing your software, along with the metadata about the software and dependencies in a well-defined format.

Packages promote code reuse, as code can be dropped into another application and used easily. Packages are created using a package manager and are usually stored in a repository, like Cloudsmith (Read our article for a more comprehensive 

The table below details some common software packages used in banking and fintech:

Cloud-Native Package Management for the Banking Industry

You know you need to secure your software supply chain. Everyone’s telling you that these days - your executives, your vendors, even 

. Your organization has an initiative to do so, or maybe they’ve brought in an expert to help you achieve this goal. But hold on a minute - do we have a shared understanding of what a software supply chain is, and what exactly makes it secure?

. The focus was getting back to the basics of what a software supply chain is, and why it needs to be secure. If you weren’t able to attend, or if you want reference material to share with others, here’s our recap.

The webinar addressed the following topics:

What does a secure software supply chain look like?

What are Cloudsmith and Chainguard doing to help solve this problem?

In the most basic terms, what is a software supply chain?

Simply put, a software supply chain includes 

 everything that contributes to making your product - the source code, dependencies, systems, tooling, environments, processes, and even the users who contribute along the way.

, Developer Relations at Cloudsmith, said that a good analogy for understanding the software supply chain is to look at another industry that also deals with supply chains - manufacturing. The manufacturing industry has a standardized way - a Bill of Materials - to detail all of the inputs into their final product. They need that because they need to ensure they have the materials required to build the physical product and that they have met safety and security standards along the way.

The software industry doesn’t have the same regulatory controls as manufacturing, though. There is no centralized authority ensuring provenance and traceability are enforced (though we may see this in the future). This gap has made space for the rise of many interesting projects designed to help make safety and security so easy, it becomes the default. Projects like Sigstore, The Update Framework, in-toto, and SLSA are just a few examples. We’ll touch more on these projects later in this post.


Why are we securing our supply chains now?

As Dan Lorenc said in the webinar, there have been voices advocating for securing software supply chains for years now. But a handful of events in the last 24 months have caused organizations to wonder why they’ve waited so long to get started.


In the spring of 2020, SolarWinds unknowingly started to send out software updates that contained hacked code. This is the event that really got everyone talking about “software supply chains”.

SolarWinds is an IT management tools company that helps businesses manage their networks, systems, and infrastructure. In early 2020, threat actors found a way into the build system at SolarWinds and managed to add malicious code into one of its products, a performance monitoring platform called Orion. Subsequently, when Orion customers updated their installations, the malicious code was included in the update, giving the threat actors a backdoor they could use to install additional malicious software, exfiltrate sensitive data, or spy on the companies themselves.

Big organizations found themselves impacted - Microsoft and Intel for example. Overnight, everyone was talking about software supply chains and what needed to be done to secure them.


In February 2021, security researcher Alex Birsan 

 were found to be vulnerable to the injection of malicious packages, via public sources, into their software supply chains.

, and it relies on package management software to download the malicious version of a package being used as a dependency. The key is to create an external library with the same name as a private internal library that a particular company uses in its development pipeline. There are then several ways that a package manager can end up accessing the malicious external version of the library.

This incident shows why it is so important to make security so easy, it happens by default. It only takes one developer with a poorly configured system for the malicious library to gain entry to the organization.

Executive Order on Improving the Nation’s Cybersecurity

On May 12, 2021, President Joe Biden issued an executive order to begin creating federal standards for security of the software supply chain. 

The Executive Order on Improving the Nation’s Cybersecurity

 orders the Department of Commerce and the National Telecommunications and Information Administration to publish minimum requirements for a 

 (SBOM). The SBOM is a record of the components and packages used in building software, whether open-source or commercial, intended to help software end-users to analyze vulnerabilities or issues with the licenses.


In February 2022, The National Institute of Standards and Technology released Special Publication (SP) 800-218, 

Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities

. At the start of 2022, the White House brought together government employees, private sector stakeholders, and members of the open-source community to discuss how to improve the security of open-source software and software supply chains. This publication is the result of those discussions, and it recommends a core set of high-level secure software development practices called the SSDF that can be integrated into each SDLC implementation.

Why is this a hard problem for organizations to solve?

One challenge is that open-source software is foundational to software development, and so for an organization to secure their supply chain, they will need all open-source software they use to also be secure. Realistically, open-source code is in every supply chain. Now, it’s important to note that the way to solve this problem 

 to remove open-source software from your supply chain. In fact, open-source software can often be more secure than proprietary software as its widespread use means it’s usually well tested. The challenge is in how to make adhering to security best practices so easy, they are not burdensome for the open-source community to adopt.

Along the same lines, for one organization’s software supply chain to be secure, the supply chain of any vendor they use also needs to be secure. You need provenance from top to bottom. To quote Paddy Carey, Senior Staff Engineer, Cloudsmith, “

.” And if no one is requiring you to adopt secure software development practices, and it’s overly burdensome to do so, what’s your motivation? So again, designing standards, tools, and solutions that make it easy to be secure will be key to the widespread adoption of secure software development practices.

As Dan Lorenc said, it will be slow until the first person adopts these practices, but then we’ll see it ripple across the industry.


First, it’s important to acknowledge that there is no one thing you can do to secure your supply chain. There are many best practices that come together to create a secure software supply chain. But it’s also important not to let that overwhelm you.

One project that is designed to help organizations understand what makes a supply chain secure and provide guidance on how to get started is 

. It’s a security framework, a checklist of standards and controls to secure packages and infrastructure in your organization. And there are SLSA levels - Level 1 is designed to be easy to achieve to help motivate folks to start the process of securing their supply chain.

NIST organizes the Secure Software Development Framework practices into four groups:

: Ensure that the organization’s people, processes, and technology are prepared to perform secure software development.

: Protect all components of the software from tampering and unauthorized access.

: Produce well-secured software with minimal security vulnerabilities in its releases.

: Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

Both the SLSA framework and NIST’s SSDF are good starting points for organizations on the journey to a secure software supply chain. And if you want the tl;dr on NIST’s SSDF, 

Dan Lorenc read NIST 800-218 so you don’t have to

Chainguard was founded in 2021 with the mission to 

make the software supply chains secure by default

. The team is working on this goal with a strong commitment to open-source projects and communities, and a willingness to take on large-scale industry-wide changes. Some key projects they are involved in:

As mentioned earlier, SLSA is a checklist of standards and controls to secure packages and infrastructure within an organization. SLSA levels are a common language to talk about how secure software, supply chains, and their components really are. From source to system, the levels blend together best practices to create four compliance levels of increasing assurance.

A new standard for signing, verifying, and protecting software, sigstore automates how you digitally sign and check components, for a safer chain of custody tracing software back to the source, removing the effort, time, and risk of error this usually comes with this.

As Dan McKinney said, Cloudsmith is excited that securing the software supply chain is now at the forefront of people’s minds, as it’s been close to our hearts for a while now. We believe that 

 - the strategy of ensuring all packages produced or consumed are scanned, verified and isolated from untrusted sources - improves security through isolation, automation, and universal hosting. Our platform enables organizations to add continuous packaging to their modern software development workflow.

Provide a single source of truth of software assets

 with support for over 28 formats, allowing organizations to manage packages across languages and formats in one place. This centralized source of truth provides visibility, control and management consistently for all packages produced or consumed by the build process, and gives organizations a single checkpoint that all packages pass through.

The goal of provenance is an unbroken chain of traceability, all the way back to the host machine that built the package. And we want to meet our users where they are when it comes to provenance. We will implement support for the signatures and attestations that our customers are adopting across all the formats we support, including but not limited to sigstore, cosign, in-toto, The Update Framework and more.

users can cache their open-source packages

 away from public upstreams. By caching packages from public upstream repositories and other external sources, you can protect yourself from issues with package availability, license changes, and emerging vulnerabilities.

First and foremost, we must acknowledge that we are a chain in our customers’ software supply chains. We are taking steps to ensure that we employ high-level secure software development practices, and exposing that information to our customers to prove to them that we are secure. Customers need to be able to trust, and verify, that their providers are securing their software supply chains, too.

Hopefully, that helps demystify software supply chains and why securing them is paramount to the software industry as a whole, and why the time to do so is now.

We’d also like to thank Dan Lorenc, the founder and CEO of Chainguard for joining us for the webinar.

Everything You Wanted To Know About Securing The Software Supply Chain

Video games are not just computer programs, they are audio-visual artistic works. It’s a collaborative effort between software engineers, animators, scriptwriters, graphic designers, photographers and sound engineers.

Working with these collaborators and assets leads to a different software pipeline than the average software project. They also have the added complication of making cross-platform games - custom optimizations for a particular platform can have the unwelcome side effect of increasing build times and complicating the build process. But when it comes down to it, it’s still a software pipeline that needs a package repository to store its artifacts.

On top of storing their artifacts, gaming developers need a package management tool that helps secure their software supply chain. Protecting and understanding the threats from the software supply chain aren’t new concepts in gaming development by any means. For years, Anti-cheat game developers have been developing ways to 

 with signed firmware to combat mods, anti-debugging software to defer piracy and hackers, and runtime integrity checks to combat cheaters.

A somewhat new avenue of attack from the supply chain is 3rd party dependencies. Gaming developers should be able to assess and manage their dependencies easily. Like other software pipelines, trust in dependencies is integral to the security of their software. Some gaming software, such as 

, can often run at a very high privilege level - the consequences of adding a dependency with a vulnerability could be catastrophic.


Gaming developers need their package management solution to:

A gaming development pipeline builds a video game from concept to completion. These pipelines have to cope with cross-platform builds, audiovisual assets, licensing, different revisions, and creative changes. They also need to contend with a distributed workforce and the security of their software supply chain. Needless to say, Gaming development has quite a complex and time-consuming software pipeline.

Cross-Platform game development allows you to code once and release to all platforms, whether mobile, console, PC, AR, or cloud gaming platforms. The big gaming platforms include Steam, PlayStation, Xbox, Nintendo, PC, Mac, iOS, and Android.

Cross-platform game development can be made more accessible with gaming engines and SDKs. The big gaming engines are Unreal and Unity (see the table below for more examples and information).

Cloudsmith blog

Recap: 2022 State of DevOps Webinar

Could 2023 be the year of memory safety?

Cloud-Native Package Management for the Banking Industry

Everything You Wanted To Know About Securing The Software Supply Chain

Package Management for Gaming Software Development

Private Package Repositories Part 2: The Influencers

Cloud-Native Pipelines: Secure Software Delivery, Made Simple Dev Week Cloud Workshop Session

Getting Started with Helm and Cloudsmith

Private Package Repositories Part 1: What’s a package again?

Intercept Security Scans with Vulnerability Webhooks

Continuous Packaging: Securing end-to-end delivery, from build to production

Getting Started with Go and Cloudsmith