devopsy.kinsta.cloud

Tag: CNCF

Digital.ai Extends Scope and Reach of DevSecOps Platform

An Erawan release of the DevSecOps platform from Digtal.ai adds an ability to automated applications security along with integration with Backstage, an open-source internal developer platform originally developed by Spotify that is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

In addition, Digital.ai is tightening its integration with the Microsoft Azure cloud platform by making it simpler to validate and manage Helm charts.

Digital.ai CEO Derek Holt said as the pace of application development starts to further accelerate, thanks to the rise of generative artificial intelligence (AI) tools, organizations will need to revisit their DevSecOps workflows. Specifically, they will need a platform with the governance capabilities required, to ensure that only code that has been thoroughly reviewed and tested makes it into a production environment, said Holt.

The company is also working toward adding generative AI tools to its DevSecOps platform to make it simpler to manage code bases that are about to rapidly expand, he noted. Digital.ai has been laying the foundation for that effort via a Digital.ai Intelligence data lake that already applies predictive machine learning algorithms to data collected by both Digital.ai and third-party partners, said Holt.

Over time, many of the capabilities of individual tools that DevSecOps teams once needed to integrate are becoming features of a larger platform to enable DevSecOps teams to better embrace platform engineering as a methodology for managing DevSecOps workflows at scale, he noted.

There are no shortage of options when it comes to DevSecOps platforms, but the ability to apply software engineering intelligence across normalized data collected from increasingly hybrid application development environments will prove crucial, added Holt.

Best DevOps Practices

It’s not clear to what degree organizations that have already invested in a DevOps platform might be willing to switch platforms in the age of AI-assisted application development. However, the number of organizations that will be able to create and deploy custom applications is about to substantially increase. Many of those organizations will eventually need to adopt a set of best DevSecOps practices at a time when governments around the world are moving to hold organizations that build and deploy software more accountable for application security.

In the meantime, DevSecOps teams should assume the amount of code simultaneously moving across pipelines will increase as developers take advantage of various generative AI tools to help them write. The challenge is the first generation of these tools has been trained using code samples of varying quality collected from across the internet. As such, the code generated by these tools might have known vulnerabilities or might not in some cases work at all. Each DevSecOps team, as always, will need to verify that code — regardless of whether it was created by a human or a machine — can be used in a production environment.

After all, the benefits of rapidly building applications are generally erased if the end-user experience deteriorates to the point where DevSecOps teams spend more time troubleshooting existing applications than deploying new ones.

June 17, 2024
Self-Hosting is Dead. Hybrid is the Way to Go

If I scroll back through my photo library, it’s astonishing how few photos I have from before 2004. And in 2006 (and probably for a few years after that), I still kept every photo I had on the hard drive of my laptop computer. If I lost that laptop, those photos would be gone forever. At some point, I went through the process to back them up to an external hard drive.

And then along came the cloud. At some point, I could give my pictures to Apple or Google and not worry about backups. There was always the possibility they could have a critical disaster and lose every wedding photo I had or all the early pictures of my kids (it could still happen). But as a father who takes way too many pictures of my kids, I no longer maintain an external drive of backups because the several terabytes of photos I have are sufficiently stored and backed up in the big cloud provider I pay to handle it. The SaaS solution in a cloud backup was more than sufficient for me.

Camera Rolls and Data Centers

Likewise, it wasn’t that long ago that any meaningful internet presence required a company to have a large server room and host their own infrastructure. That meant racks and racks of computers and an enterprise internet connection to make sure customers could access those racks of computers. Most services you relied upon had to be close by physically to deal with latency and ensure the experience worked for your customers.

Logging and metrics were kept locally, as were backups. I’m sure I’m not the only one who remembers swapping out big tape drives for daily backups and storing them in large plastic bins somewhere we really hoped wouldn’t flood.

If you were using a significant piece of software, you would need to self-host that software for many reasons—but the biggest reason was that shared infrastructure wasn’t a reality yet. There was no way to share hardware and no meaningful way to share software in a multi-tenant environment.

IaaS, the Cloud, Automated Backups and SaaS

Today, the infrastructure-as-a-service (IaaS, or “Cloud”) providers are offering everything from email hosting to Kubernetes-as-a-service (KaaS), from serverless to logging. They even make sure the software that enables your edge computing is obscured from you and managed by them (backups are automatic! And included in the price! And happen without a single person touching a tape drive!). This frees us up significantly to spend time shipping code and bits instead of fiddling with wires, CPUs and drives. It’s like shipping your photos to a SaaS photo storage provider—it takes the headache and the worry away. Yet when companies move to the cloud, many maintain the “old way” of doing things because they haven’t adjusted to the new reality yet.

There is now no need to self-host your own email service. The cloud provides it, or you can use a third-party service that runs in the same cloud. Data proximity is no longer a concern, and latency won’t suffer. Similarly, there is no need to self-host your backups or even your logging service—because the cloud will provide it, and similarly, a third-party service is no longer a latency concern—that third party is probably hosted by the same cloud in the same region.

This move to the cloud and shared infrastructure has been a game changer. SaaS is the name of the winning solution. Still, there will always be some companies with compliance or security needs that want to maintain data residency, just like there will always be people with such sensitive data or important family photos that no matter how safe and reliable the cloud is, they’ll insist on self-storage for photos and backups.

The Hybrid Solution

That’s why a hybrid cloud is the future of cloud-native solutions for complex enterprise applications and data. You host the data, but the SaaS provider hosts the application. The data stays under your control, but the SaaS firm updates the application regularly. Today, a large enterprise may have five engineers just to handle a self-hosted version of a logging app. At $180,000/year per engineer (a reasonable tech salary today), that’s almost a million dollars per year to maintain a software product that the vendor will gladly maintain for you.

This is a simple shift, but it has only become a reality recently due to advances in technology, the things the cloud has enabled and the increased headache—now seemingly unnecessarily dated—of self-hosting (and then upgrading and patching) software built by a third party.

With a hybrid cloud offering, you’re always using the latest version of the software because you’re using the software hosted and updated by the SaaS provider. There is no need to self-update, scale up or down or security patch a self-hosted install. The SaaS provider handles the compute and scaling required to make the service run smoothly. And you get the best of both worlds — zero software maintenance while still keeping your data in your own hands.

To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.

February 29, 2024
Best of 2023: Are We Witnessing the End of Open Source?

As we close out 2023, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.

Hailed as a groundbreaking movement in software creation, open source software has become an indispensable pillar of modern software development. Often described as democratized technology, it has empowered countless individuals and organizations to collaborate and innovate. However, the community now stands at a critical juncture, and there’s some speculation that we’re seeing a decline in the open source space.

Why is Open Source so Popular in Modern Software Development?

At the heart of open source lies the power of collaboration. Unlike proprietary (closed source) software, open source invites participation from a diverse range of contributors, allowing them to work collectively to create and improve software. This inclusivity fosters shared knowledge and cooperation, leading to the creation of groundbreaking software.

In addition to collaboration, the open source development approach eliminates financial barriers and significantly enhances accessibility in software development. With open source software typically distributed under licenses that allow users to access, use, modify and distribute the software freely, this eliminates the need for costly licenses usually associated with proprietary software. This affordability allows organizations of all sizes to leverage innovative solutions without accruing high upfront costs.

Within the framework of open source software, transparency is ingrained. The accessibility of the source code makes it possible for users and contributors to scrutinize the source code, promoting trust and accountability. By promoting scrutiny and peer review, transparency ensures that flaws are quickly identified and addressed. It also empowers users to have greater control over their choices in technology.

With these benefits coupled with success stories from enormous projects like Linux, Apache and MySQL, open source positioned itself as having the potential to compete with proprietary alternatives, leading to widespread adoption across the technology industry.

More Projects are Jumping Ship

Given these numerous benefits, one might wonder: What challenges could arise with this approach? In recent years, there have been sentiments amongst contributors that the space might be losing steam. Their concerns are fueled by a few key factors that may erode or undermine the collaborative essence of the movement.

A huge factor is the commercialization of open source projects. A popular example of this phenomenon is the GitHub acquisition – GitHub, the home for open source projects for years, was acquired by the tech giant Microsoft in 2018. This news ruffled some feathers in the community, as Microsoft was seen as a proponent of proprietary software. It also raised doubts about whether GitHub would maintain autonomy over its decision-making process.

Regardless of these doubts, the community overcame the bump in the road rather quickly and continued contributing to the platform for years. However, in 2022, GitHub announced that a sub-program called Copilot, which open source developers had been working on, would emerge as a commercial product, with the profits going to GitHub itself. This development infuriated community developers, and they faced a rude awakening that any open source platform could decide to commercialize their projects without contributors sharing in the financial rewards or even gaining recognition for their work. Another open source project that has fallen victim to commercialization is OpenAI.

There have also been increasing concerns about whether open-sourcing core business models will cause more harm than good. Unlike in the past, it’s a lot easier for projects to become popular, creating a high possibility that someone else can steal the idea or offering and quickly create a commercial product based on the project.

These considerations are part of a broader discussion regarding the shifting dynamics and potential departure from the core principles within the community, causing participants to be uneasy.

The Dust Settles: Open Source Remains Strong

Despite the concerns and challenges facing the community, open source has undeniably transformed how we build and deploy software. We must approach the future of the movement with cautious optimism.

Drawing from past experiences like GitHub and OpenAI, it is clear that the community is resilient and adaptive. Contributors who do not agree with the acquisition of GitHub or the commercialization of OpenAI will take their gifts and contribute to projects whose values they agree with.

However, open source is at a crossroads and is grappling with challenges and changes that demand introspection. This introspection, hopefully, will lead to adjustments in the open source space that reaffirm its core principles and address concerns. Open source is not fizzling out, at least not yet; we can think of it as undergoing a transformative phase that will shape its future and ensure that it remains an important pillar in the software development landscape.

To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.

December 22, 2023
Measuring the Progress of the OpenTelemetry Project

The biggest compliment you can pay a technology standard is to say that it is “boring.”

Transport layer standards like TCP and UDP are boring. They are the underlying protocols powering pretty much everything we do on the internet. REST is boring. It brokers trillions of API transactions across the world’s distributed microservices.

Infrastructure standards get boring when they become common infrastructure plumbing that “just works.” They give open source creators and maintainers common foundations to innovate on top of. They give users confidence that their technology choices aren’t leading to dead ends. Look at any major evolution in computing, and it’s always propped up by boring standards.

When OpenTelemetry debuted at KubeCon in 2019, telemetry data for applications in distributed systems was far from boring. Two competing projects—OpenTracing and OpenCensus—were trying to encapsulate best practices around the still nascent distributed tracing discipline. They were “very similar in that they aim[ed] to unify app instrumentation and make observability a built-in feature in every modern application” (Merging OpenTracing and OpenCensus: Goals and Non-Goals). But having two fragmented communities around these two projects made it hard for distributed tracing to move forward—so it was a big deal when the two projects merged and OpenTelemetry was born.

Let’s take a look at how the OpenTelemetry standard is making this all possible.

Standard Semantic Conventions and a Single ‘Mental Model’

Semantic conventions are important to standardize how we describe common operations so that we have consistent telemetry for similar actions. Developers instrumenting applications need to be able to relate to clear semantic definitions to understand how to instrument everything from database drivers to SQL statements and how to consume that telemetry data for analysis.

For example, OpenTelemetry semantic conventions define where in the metadata the process name should be stored, but not what the process name should be. Similarly, if I’m deploying my application on Kubernetes on a cloud provider somewhere, I’d expect my telemetry data to have the Kubernetes pod and namespace it originates from, as well as the cluster and region.

OpenTelemetry also standardizes metadata for labels that span languages. So if I have an HTTP service and request, it doesn’t matter if it is in Java, Python or any other language — with OpenTelemetry, I can just start querying the data without having to think about the language behind it.

It brings a consistent mental model to how the different telemetry data types (traces, metrics, logs) are related: OpenTelemetry gives them the same base, so understanding how a span is modeled provides knowledge that can be reused when understanding metrics and logs. It can be used by any microservice and any HTTP- or gRPC-connected service or device. For any network device, OpenTelemetry gives developers semantic conventions that bring consistency to reporting telemetry data on any type of event. So, any engineer working with OpenTelemetry can compare latencies and queries between services—even if they are written in different languages—because of the semantic conventions.

Protecting Users From Vendor Lock-In

A decade ago, monitoring and logging vendors provided agents to their customers. They didn’t call it observability back then. But they told the market that if you want the best telemetry data, you need to use our agent. Every vendor had its own agent.

Adding these agents was risky and took a lot of time. Once a vendor got its agents into a customer’s environment, they were hard to change and you had to either pay the vendor or your team of engineers to remove that instrumentation in favor of another.

OpenTelemetry really commoditized the telemetry definition in such a way that we don’t need to use agents from vendors anymore. This means users can decide which vendor to use for observability tooling and have the flexibility to switch to different vendors down the line. With OpenTelemetry, they no longer have to instrument applications, restart applications and get into risky operations cycles to change the destination of their telemetry data.

Economies of Community – Scale for Drivers and Integrations

OpenTelemetry has achieved a very large and diverse set of contributors in a relatively short period of time. It’s become the second most popular CNCF project, behind only Kubernetes.

The project is drawing contributions both on the instrumentation side of things, as well as the collection side of things. Specifications are another big area where the project is evolving, including the API/SDK spec, the data model and the OTel protocol (OTLP). Accelerating all of this is the fact that OpenTelemetry has broad participation from the logging, monitoring and observability vendor ecosystem, which comprises many of its largest contributors.

We still have a ways to go. But in the last year, it’s become obvious that OpenTelemetry is so commonly regarded as the standard for tracing data that the language, library and database creators and maintainers are instrumenting for OpenTelemetry. This is the ultimate sign of maturity for any project or standard—when its popularity has created pull from maintainers designing around the spec and using it natively.

What’s Next For OpenTelemetry?

Looking to the future, I think we’re going to see an unintended consequence where OpenTelemetry moves the industry from operational data to more data intelligence. OpenTelemetry makes it much easier to instrument how users are interacting with systems and enables developers to add business metrics and compare those against actual user behavior.

OpenTelemetry also has a great potential marriage with eBPF and related projects like Cilium. These abstractions that make the Linux kernel “programmable” add a pool of much finer-grained telemetry data that can be extracted into logs from applications during run-time.

This all feeds into the concept of “Profiles” that OpenTelemetry is implementing. While distributed tracing emphasizes the horizontal cut of how a specific transaction is running or all the services that are tied through a single request, a profile is a different vertical cut that emphasizes the state of resources like memory, CPU and more at a point in time. Those profiles are collections that are stored continuously and another great slice of telemetry data that will be encapsulated by the OpenTelemetry standard.

October 31, 2023
Graduation Days

July 17, 2023
Cisco Bets on OpenTelemetry to Advance Observability

Cisco today announced a technology preview of a Cisco Full-Stack Observability Platform based on instances of open source OpenTelemetry agent software being advanced by the Cloud Native Computing Foundation (CNCF) to collect metrics, event, logs and distributed traces. The Cisco Full-Stack Observability platform will be available in June 2023.

The platform, announced at a Cisco Live EMEA event in Amsterdam, Netherlands, will combine the capabilities of multiple Cisco platforms and technologies into a single offering.

At the same time, the company also announced the bidirectional integration between its existing Cisco AppDynamics application life cycle management (ALM) tool and the Cisco ThousandEyes network monitoring platform beginning in April.

Finally, Cisco is making available a Business Risk Observability offering to provide business risk scoring. Business Risk Observability combines capabilities of its Kenna Risk Meter tool—gained when Cisco acquired Kenna Security in 2021—with the ability to monitor business transactions through Cisco AppDynamics to provide better visibility into application security. In addition, Cisco has integrated its Panoptica application programming interface (API) management security tool and the Talos threat intelligence platform within the Business Risk Observability Platform.

Carlos Pereira, a Cisco fellow and chief architect for strategy, incubation and applications at Cisco, said Cisco is moving to narrow the historic divide between application development and cybersecurity teams to enable organizations to adopt DevSecOps best practices and make it simpler to prioritize the remediation of vulnerabilities that are likely to have the most impact on the business.

Like most providers of observability platforms, Cisco is betting that more applications will be instrumented as OpenTelemetry software continues to mature. Cisco is now the single largest contributor to this project, noted Pereira.

OpenTelemetry will also play a critical role in improving application security as more applications become instrumented, he noted. In fact, a recent Cisco AppDynamics survey found more than three-quarters of respondents (76%) believed that DevSecOps is essential for organizations to effectively protect against a multi-stage security attack. However, only 43% reported their organization had started implementing DevSecOps workflows.

Observability, of course, has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications, interest is rising in observability platforms that make it simple to investigate anomalies indicative of an issue that could disrupt an application environment. Most of those observability platforms are infusing those platforms with machine learning algorithms to surface those anomalies as part of an effort to augment the capabilities of a DevOps team.

Regardless of the approach to observability, many organizations will soon be trying to determine whether to rely on existing monitoring tools that make it possible to track pre-defined metrics. In some cases, there may still be a need for that legacy approach to managing IT. Still, in other instances, it may be possible to rationalize some of those platforms in favor of a more advanced approach that relies on a more advanced approach to achieving observability.

February 7, 2023
Critical Vulnerability Discovered in Open Source Backstage Platform

Oxeye today disclosed that it has discovered a critical vulnerability in the open source Backstage software used to build developer portals. Backstage was originally created by Spotify.

A 1.5.1 update to the Backstage platform remediated a sandbox escape vulnerability that can occur via a third-party Scaffolder plug-in that could be used to conduct unauthenticated remote code execution (RCE).

Oxeye CTO Ron Vider said Oxeye worked with Spotify to responsibly disclose the issue and enabled a patch to be created prior to the disclosure of the vulnerability, which Spotify gave a 9.8 out of 10 severity rating.

Backstage is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), but is already widely used by organizations such as American Airlines, Netflix, Splunk, Fidelity Investments, Epic Games and Palo Alto Networks, as well as by Spotify.

The vulnerability is another example of a potential template-based attack through which run shell commands can be manipulated to inject malware into an application development environment.

In general, separating the logic from the presentation layer as much as possible can greatly reduce exposure to the most dangerous template-based attacks.

Vider said Oxyeye is focusing its vulnerability research on cloud-native platforms such as Backstage that are generally being used to build modern applications based on a microservices architecture. It’s not clear to what degree organizations have transitioned away from more monolithic approaches to building applications, but it’s clear that a much larger percentage of applications are now being constructed using microservices.

Cybercriminals, of course, are targeting these platforms as part of a sustained effort to compromise software supply chains in the hope that the malware they inject will find its way into multiple downstream applications. Those attacks, in turn, are convincing more organizations to embrace DevSecOps best practices to better ensure the integrity of their software supply chains. The challenge is many of those attacks are being aimed at open source software projects that don’t always have enough resources to quickly develop a patch in the event a zero-day vulnerability is disclosed.

While it’s impossible to know the extent to which cybercriminals are already exploiting vulnerabilities in DevOps platforms, the level of cybersecurity scrutiny being applied has dramatically increased in the wake of a series of high-profile breaches. The Biden administration has even gone so far as to issue an executive order requiring federal agencies to better secure their software supply chains. As a result, DevOps teams should expect there to be a lot more DevOps platform vulnerability disclosures in the months ahead, and that those vulnerabilities will require immediate patching.

Like it or not, software supply chains are going to become more secure. The only thing left to be determined is the level of pain that will be experienced as more vulnerabilities are discovered in the DevOps platforms that were used to construct them.

November 15, 2022
CloudNativeDay: WASM to Drive Next IT Epoch

WebAssembly (WASM) is poised to drive the next era of development of cloud-native applications that can truly run anywhere.

Liam Randall, CEO of Cosmonic, a provider of a platform for building and deploying WASM applications, told attendees at a virtual CloudNativeDay event that WASM will be at the core of a new IT epoch that will enable organizations to more quickly build highly portable applications that are not tied to any IT infrastructure platform and more secure.

WASM, at its core, is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The World Wide Web Consortium (W3C) drove the development of WASM as part of an effort to create a common format for browsers executing JavaScript code. Wasm is now being extended beyond browsers and JavaScript to enable developers to create a set of universal binaries that could work on any platform without modification.

That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries between them. One of the issues of that approach is that it becomes relatively simple for malware to infect all the components of an application.

The Cloud Native Computing Foundation (CNCF) is now trying to advance the adoption of a Cosmonic’s WASM runtime that makes it possible to run WASM applications on any platform versus being constricted to building applications that can only run, for example, on Windows or Linux.

That level of portability will prove crucial as more organizations look to drive application deployments on a wide range of edge computing platforms, noted Randall.

It may be some time before WASM becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are finally starting to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. That’s not only critical in terms of overall application developer productivity, it has major implications in terms of streamlining the management of DevOps workflows as it becomes easier to both initially deploy applications and continuously update them.

In the meantime, as organizations continue to review their application development practices to better secure software supply chains, it’s become clearer that legacy approaches to building applications are fundamentally flawed. Rather than attempting to reengineer processes to encourage developers to better secure applications, it may be more effective to change the way applications are built. After all, considering all the processes required to secure legacy approaches to application development, it may be cheaper and easier to adopt a new app development method.

The challenge, of course, is, as always, taking that first initial step away from the inertia of legacy application development approaches.

August 10, 2022
Appstellar Is Now a Kubernetes Certified Service Provider and Silver Member of CNCF and Linux Foundation

Appstellar is excited to announce that they are now a CNCF Silver Member, Kubernetes Certified Service Provider (KCSP), and a Linux Foundation Silver Member.

We at Appstellar, are thrilled to announce we’re now a CNCF Silver Member, Kubernetes Certified Service Provider (KCSP), and a Linux Foundation Silver Member! Read more about it on the CNCF new members announcement.

This is a big milestone that demonstrates Appstellar’s expertise as a cloud and DevOps solutions provider helping customers embark on their Kubernetes and cloud-native journey. A lot of work has been done to get here, so we’re super proud and excited to finally receive the KCSP badge.

Since focusing our services strictly on cloud software development and DevOps solutions, we’ve implemented Kubernetes practices for multiple clients in industries such as fintech, healthtech, and others. Having said that, the KCSP certification will help show Appstellar’s extensive expertise in supporting organizations to move to a cloud-native platform.

As a Kubernetes Certified Service Provider with Cloud Native Computing Foundation, Appstellar will continue to offer Kubernetes support, consulting, and professional services for businesses and organizations wanting to migrate to cloud technologies, or improve their existing cloud infrastructure.

On the other hand, as a member of the CNCF and the Linux Foundation, Appstellar commits to expanding the Kubernetes and cloud-native ecosystem and bridging the gap between developers and operations.

“We’re proud to be the first Kubernetes Certified Service Provider in Kosovo and the Westerns Balkans” say Co-Founders of Appstellar – Rozafe Llalloshi and Mehmetali Shaqiri.

As for Appstellar, we are currently in hyper-growth mode. In the past 6 months, we’ve grown our team by 122%! Moreover, we’ve signed multiple new client deals, expanded in new industries of operation, and also moved to new office spaces.

In addition to these partnerships, Appstellar has also become an AWS partner. With these partnerships, we look forward to accelerating our growth even further and taking on projects we love to work on.

Here’s to continued success!

May 20, 2022
Announcing the Refreshed Cloud Native Security Whitepaper
The CNCF Security Technical Advisory Group (TAG) has just released a refreshed Cloud Native Security Whitepaper v2 to help educate the community about best practices for securing cloud native deployments. The whitepaper intends to provide organizations and their technical leadership with a clear understanding of cloud native security, its incorporation in lifecycle processes, and considerations for determining the applicability of standards such as NIST SSDF. The first version of the whitepaper was released on Nov 18, 2020. The paper has been translated into different languages and an audio release of version 1 can be found here.

“In the past 18 months, the security industry and our group has evolved with attacks on supply chain and ransomware in the limelight. We received excellent feedback on improvements to the first version of the paper as part of a months-long retrospective process. Our group has also grown with multiple supplementary material like Secure Supply Chain Security Whitepaper, Cloud Native Security Map and Lexicon published since the first version of this paper. As a sign of the vibrant community, just like the first version, the people across the community brought their passion, skill sets and expertise to address end user feedback and growing pains in the Cloud Native Security space” said TAG Security Tech Lead Pushkar Joglekar.

While the large majority of the original paper, stands the test of time, this refreshed version demystifies security assurance and compliance by walking through specific use-cases of ransomware incident handling and how to secure financial institutions under EU regulations. Feedback from readers of the original paper is also addressed through inclusion of these new sections:
- Secure Defaults – Cloud Native 8: A high level guidance on implementing cloud native apps that are secure by default.
- SSDF v1.1 mapping: Maps the NIST SSDF practices and tasks to Cloud Native Security Application Lifecycle
- ATT&CK Threat matrix for Containers: Summary of how the threat matrix provides a structure towards applying guidance described in this paper
- Guidance on how to share feedback: Instructions on how to share feedback on the paper is now part of the paper with a short summary on how feedback was collected and addressed after publication of the first version.
The CNCF Security TAG aims to facilitate a vendor neutral collaboration to discover and produce resources that enable secure access, policy control, and safety for operators, administrators, developers, and end-users across the cloud native ecosystem. If you are interested in participating in the Security TAG, check out the Charter for more information and please come say “Hi!” on #tag-security channel on CNCF Slack.

The whitepaper is available on GitHub.
May 18, 2022