devopsy.kinsta.cloud

Category: DevSecOps

What DevSecOps for SAP Looks Like
In the past few years, organizations have seen a constant increase in cyberattacks targeting business-critical applications and the data within because that data is particularly lucrative to sell or trade. Organizations running SAP software, especially, are struggling, as SAP systems are complex and hard to patch—even worse, information security and cybersecurity teams often don’t understand SAP systems and how to secure them. Traditional security approaches aren’t enough to secure SAP systems, but DevSecOps for SAP could introduce a new approach with better results.

What is DevSecOps?

While traditional security often becomes a roadblock to accelerated software delivery. DevSecOps introduces a new security-first mindset that emphasizes security at every step of the software development life cycle and makes everyone in the organization responsible for security.

DevSecOps includes all departments of an organization and embeds security thinking into the entire process, from the executive board down to individual teams. To make this successful, business operators need tools and processes that support:

Continuous monitoring

Scanning for security defects

Attack detection

Change management and governance

Regular assessments

Why is DevSecOps for SAP Changing the Game?

In the past, security was often neglected while implementing new projects or new feature releases under the assumption that security defects would be resolved later in an existing system by the information security team. This approach, however, introduced additional complexity, costs and business disruption.

If security considerations are introduced in an earlier phase of a project, security defects can be identified and remediated much more cheaply and quickly. This alone makes it far more efficient and easier to resolve a potentially exploitable vulnerability. With good tools in place, this becomes very efficient and allows organizations to identify and resolve vulnerabilities that have been introduced in earlier iterations of their change processes.
The biggest benefit, however, is that any new process or feature has been implemented with security by design, leading to a resilient environment that can more easily fend off cyberattacks.

DevSecOps for SAP

Here’s an example: Say a new business project is started with the intent to change SAP applications or processes to introduce new functionality. Like with any project, time, budget and available resources are key elements. For DevSecOps to work, important security considerations must be made in early phases of the project. In reality, every single project is a security project. This means that business requirements and targets must not be prioritized over security concerns. Processes and tools are needed to enable development and security teams to work together to answer important questions: Will the project introduce a security impact to contained data and established processes? Similarly, is there a need for additional software and security architecture, or is a specific skill set required that needs to be onboarded to the project?

In an agile environment, once all epics and user stories have been written, the design phase can start. With a security mindset embedded into the project, this will automatically lead to a solution that is secure by design.

During the implementation phase, developers need tools to scan for potentially vulnerable source code.

Identifying vulnerabilities that allow SQL injection, cross-site scripting or missing authorization checks early on in the development process makes it easier to fix them.

The challenge here is that SAP does not provide the tools developers need to validate source code for security flaws. The SAP transport management system is vulnerable to software supply chain attacks unless appropriate security patches have been installed. For this reason, organizations need a code vulnerability analyzer that can be integrated within the SAP standard development IDE.

In addition, quality gates enabled in the SAP transport management system can be very helpful for developers to avoid source code that lacks proper security validation.

Functional issues discovered in the user acceptance test (UAT) phase must also trigger a restart of the validation cycle. Only when all security and functional requirements are met can production deployment be initiated. In this phase of the life cycle, DevSecOps for SAP focuses on monitoring to enable attack detection, regular (or better continuous) vulnerability assessments and accurate security patching.

Which Tools are Needed to Introduce DevSecOps for SAP?

While many organizations already make use of change management and IT service management solutions, they do not yet have all the tools needed to embark on a DevSecOps journey with SAP.

Keep in mind there are platforms available on the market with an open API that allows integration within already established SAP solutions and provides the missing link between change management and security incident management. These solutions provide a one-stop-shop to securing SAP and reduce TCO compared to individual siloed tools for code scanning and vulnerability management.
April 12, 2022
Radware Embraces APIs to Improve AppSec Across Multiple Clouds

Radware this week launched an application programming interface (API) approach to securing multiple clouds designed from the ground up to be an extension of a DevSecOps workflow.

Eyal Arazi, a senior product marketing manager in Radware’s security group, said that Radware SecurePath makes it possible to invoke any of the company’s cloud security offerings via an API. That eliminates the need to depend on inline security platforms that require separate consoles to be managed.

Instead, the out-of-path approach enabled by Radware makes it simpler to consolidate the management of security across multiple clouds, he said. The API approach allows application requests to go directly from the client to the application server and reduces complexity and latency, eliminates routing changes and increases overall availability, noted Arazi.

DevOps teams can now access the entire Radware cloud security portfolio, including the Radware web application firewall (WAF), API protection tools and a service that thwarts distributed denial-of-service (DDoS) attacks via a consistent set of APIs, said Arazi. Radware will continue to make those offerings available to be deployed inline or out-of-path as IT teams see fit, he added.

Every time an organization deploys workloads on another cloud platform, an already complex security challenge becomes more complicated. Today, most of the responsibility for securing those clouds lies with cybersecurity teams. However, as DevOps teams gain access to tools and platforms that make it more feasible for developers and DevOps teams to programmatically manage security, more of the responsibility for it is shifting further left.

Part of the benefit of that approach is the elimination of the need to deploy and manage firewalls on virtual machines or the need to reroute traffic via content delivery networks (CDNs) to inspect traffic, noted Arazi. It also enables the Radware security offerings to piggyback on the certificates that are already being employed in cloud platforms, he added.

In the longer term, the goal is to reduce—or outright eliminate—the vulnerabilities that now routinely make it into production applications. Many of the cloud security issues that organizations regularly face can be traced back to misconfiguration mistakes made by developers. It’s not that a developer deliberately sets out to build and deploy vulnerable applications. Rather, they simply lack the expertise required to make sure that, for example, ports are not left open. In the absence of that expertise, more tools must be embedded within DevOps workflows to better ensure application security. After all, it may be years before most developers attain any meaningful cybersecurity proficiency.

In the meantime, closer collaboration between DevOps and cybersecurity professionals is required. There are simply not enough cybersecurity professionals available to participate in every phase of an application development project. DevOps teams need to be able to identify and remediate issues as early as possible. Otherwise, a cybersecurity issue that gets discovered at the last minute is likely to prevent a workload from being deployed in a production environment.

In the absence of any additional effort, it’s really only a matter of time before cybercriminals become more adept at compromising cloud application environments.

April 8, 2022
DevSecOps in Azure
DevSecOps is everywhere, and chances are your organization is shifting toward this convergence of development, security and operations. In an on-premises environment, you build your own DevSecOps process by mixing and matching existing and new tools. However, in the cloud, much of the environment is determined by your cloud provider. Microsoft’s Azure cloud is known for its robust security capabilities. Specifically, Microsoft has developed a set of capabilities and services that can help you ease into a DevSecOps workflow without much effort. The tools are pre-integrated and support everything from CI/CD to identity management. Let’s see how they work.

What is DevSecOps?

Security is an important part of DevOps. But it can be challenging to ensure that software developed in a CI/CD process is really secure.

DevSecOps is an organizational pattern that can make this possible, even at high development velocity. It is an approach the DevOps team can use to prevent security issues from the outset of the development life cycle, ensuring their software is not only high quality but also secure and resilient to failure.
DevSecOps is a discipline that combines application development, security, operations and infrastructure-as-code (IaC) with an automated continuous delivery cycle. Here are three practices that can help a team move towards a DevSecOps process:

Focus on average detection and recovery times—These metrics show how long it took to detect a breach and how long it took to recover. This can be tracked through continuous field testing. Improving these indicators should be an important consideration when evaluating potential policies.

Defense in depth—Every component in the architecture should be secure so that if and when attackers manage to compromise the system, there are multiple security measures and controls holding them back. This puts an end to the notion of a ‘secure perimeter’ that the organization must defend at all costs. Each component must have its own secure micro-perimeter—this is a zero-trust approach.

Continuous learning—Teams should conduct regular assessments of security practices and their environment, especially after security incidents. Every time a security incident is discovered and resolved, the team must evaluate what went wrong in the development life cycle, explore how it enabled the incident and identify ways to improve the process.

Features and Services That Enable DevSecOps in Azure

The Azure cloud provides several built-in capabilities that make it possible to adopt a DevSecOps process.

1. Azure DevOps

Azure DevOps provides developer services that enable teams to plan tasks, collaborate on code development and build and deploy applications. Azure DevOps supports a collaborative culture and process in which developers, project managers and contributors work together to develop software. You can use Azure DevOps Services in the cloud or Azure DevOps Server on-premises.

2. Build and Deploy Containers With Azure Pipelines

You can integrate Azure Pipelines, the Azure cloud’s CI/CD solution, with your Kubernetes clusters. Use the same YAML document to build multi-stage CI/CD pipelines.

Azure Pipelines lets you track metadata, such as commit hashes and issue numbers, from Azure Boards into container images. This provides direct traceability from any security issue to a specific change made in development. It also provides clear, easy-to-read documentation that can improve the feedback loop between development, operations and security teams.
3. Run and Debug Containers with Dev Spaces

When developing Kubernetes applications, there is a need to test applications locally and understand how they interact with dependent services. You may need to develop and test multiple services in collaboration with other developers or teams.

Azure provides Bridge to Kubernetes, which lets you run and debug code on your development machine while connecting to your Kubernetes cluster. You can test your code end-to-end, set breakpoints on code running on the cluster and share your development cluster among team members. This makes it possible to test and resolve Kubernetes security issues in a realistic environment before deploying to production.

4. Manage Identities and Access with Azure AD

The Microsoft Identity Platform takes the Azure Active Directory (Azure AD) developer platform one step further. It allows applications to accept logins from any Microsoft identity, and obtain tokens that can be used to call Microsoft APIs or APIs created by other developers. This creates a large, interoperable ecosystem.

Azure Active Directory B2C provides B2C identity services—customers get single sign-on (SSO) access to applications and APIs using their preferred social, enterprise or local account ID. Another option is to integrate Azure AD with on-premises Active Directory for hybrid and Azure migration scenarios.

You can also use Azure Role-Based Access Control (RBAC) to manage access to cloud resources. RBAC lets you manage who can access your Azure resources, what they can do with them, and which regions can access them.

You can also use the Microsoft Identity Platform to protect DevOps tools themselves, including native support for Azure DevOps and integration with GitHub Enterprise.

5. Manage Keys and Secrets with Azure Key Vault

Exposed secrets are a severe security issue that is very common in modern applications. Azure Key Vault lets you manage the distribution of secrets by storing them centrally in Azure Key Vault. Key Vault greatly reduces the chance of accidentally disclosing secrets. With Key Vault, application developers no longer need to store credentials or other sensitive information in their application code.

6. Azure Policy and Azure Security Center

Azure Policy lets you specify a default allowed configuration that is automatically applied to all cloud resources. This can avoid misconfigurations that violate security policies. Azure Policy works on the basis of desired state configuration (also known as declarative configuration), letting you specify to what degree resources and services should be secured and whether to alert or block/modify deployments in Azure if they don’t meet the policy.
When using Azure in multi-tenant mode, policies can be applied at the management group, subscription or resource group level. You can define specific policies and enforce compliance requirements for test, staging, and production environments.

The Azure Security Center (ASC) and Advisor can also be easily integrated into the DevOps process. ASC makes it possible to augment event streams in Azure with threat intelligence or analysis by third-party security tools.

7. Penetration Testing

Penetration testing is the recommended method for examining your environment for infrastructure or application configuration vulnerabilities that could create vulnerabilities that an attacker could exploit.

An Azure penetration test should check for vulnerabilities on endpoints, apply fuzzing (malformed input) to discover business logic vulnerabilities, and perform port scanning to identify network vulnerabilities.

Microsoft provides specific guidance for penetration testing in Azure with recommended products and penetration testing service providers.

8. Configuration and Infrastructure Scanning

To ensure security for cloud subscriptions and resource configuration across multiple subscriptions, you can use the tenant security solution part of the Secure DevOps Kit for Azure (AzSK).

In addition, you can leverage Microsoft security technologies like Microsoft Defender for Cloud and Microsoft Sentinel. These solutions provide monitoring and security features designed to detect and alert on unusual events or configurations that require investigation and possible remediation.

Conclusion

In this article, I introduced DevSecOps and showed how the Azure cloud provides a range of services that let you easily implement DevSecOps practices. These include:

Azure DevOps: The venerable toolset with strong support for DevSecOps environments.

Azure Pipelines: The home-grown CI/CD product.

Azure AD: A comprehensive zero-trust identity management solution.

Azure Policy and Security Center: Enables unified control over security policies for cloud automation and security visibility over cloud workloads.
I hope this will be useful as you take your first steps to practice DevSecOps in the cloud.
April 8, 2022
Google Allies With GitHub to Secure Software Supply Chains

Google today revealed it has been working with GitHub to create a forgery-proof method for signing source code as part of an ongoing effort to better secure software supply chains.

Bob Callaway, technology lead for open source software supply chain security at Google, said a prototype of this method, written in the Go programming language, generates non-forgeable provenance using GitHub Actions workflows for isolation and code signing tools for authenticity provided by Sigstore. Projects that make use of GitHub runners to run jobs can now achieve the third level of security as defined by the supply chain levels for software artifacts (SLSA) framework to assure software artifacts are authentic and trustworthy, he said.

The reusable workflow also protects against possible interference from maintainers who could otherwise try to define the workflow in a way that interferes with the builder. The only way to interact with a reusable workflow is through the input parameters it exposes to the calling workflow, which prevents maintainers from altering information via variables, steps, services and defaults.

The goal is not only to ensure the provenance of individual software artifacts but also make it possible to identify which build system was employed to create that artifact, said Callaway. In addition to working with GitHub, Callaway added that Google expects to apply this method to securing other build systems that organizations used to construct applications.

Overall, Callaway said, Google is also working toward embedding security functions with DevOps platforms to ensure the integrity of software supply chains, in addition to educating developers on how to build more secure software.

To protect against the possibility of one job tampering with artifacts used by another job, Google’s method creates a trusted channel. Job outputs send hashes that are then used to verify the binary received via the untrusted artifact registry. The OpenID Connect (OIDC) protocol, which GitHub just opted to support, is then used to prove the identity of the workflow to an external service, such as Sigstore, by attaching a unique JSON web token (JWT) to each runner. The token contains verifiable information about workflow identity such as the caller repository, commit hash, trigger and the current workflow path and reference.

That makes it possible for the workflow to prove its identity to the Fulcio root certificate authority provided by Sigstore. Fulcio signs a short-lived certificate attesting to an ephemeral signing key generated in the runner. A record of that signing is kept in Sigstore’s transparency log Rekor. Users can then rely on the signing certificates to verify provenance in a way that is authenticated and non-forgeable. That approach means maintainers don’t need to manage or distribute cryptographic keys for signing, which until now have made it challenging to manage code signing at scale, Callaway noted.

In the wake of a series of high-profile security breaches involving open source software, Google and others have significantly increased the resources being applied to securing both open source and proprietary software within the context of a set of DevSecOps best practices. It may be a while before the benefits of that effort are pervasively employed by developers, but it’s clear that substantial progress is being made involving everything from the tools developers use to the build systems managed by DevOps teams.

April 7, 2022
Facebook Bans Innocent Users | Azure and ARM/Ampere | ‘Great Resignation’—No End in Sight

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: No remedy for banned Facebook users, new ARM-based VMs on Microsoft Azure, and The Great Resignation will still be a Thing for the foreseeable. (more…)

April 6, 2022
Security Debt: Speed vs. Common Sense

A couple years ago, we had some spectacular security events that involved DevOps and Kubernetes, where the managing team simply redeployed containers whenever one crashed. It turned out that many organizations were doing the same thing, and, what’s worse, they were not talking about it because they knew it was not a long-term solution to crashing issues.

At the time, I thought these high-profile lessons would teach people to actually fix code issues, even in high-throughput Agile-meets-DevOps shops. I admit I also laughed, yet again, at The Phoenix Project’s expense, thinking, “Yeah, but the CISO isn’t holding things up by demanding that get fixed!” I wish that would ever get old, but it won’t.

It seems I was wrong. Or at least partially so. Some—perhaps many—shops seem to have missed the message that these issues sent. Anecdotally, we heard this was still happening, so we started asking questions. Yep. There are shops out there (since we started with ‘anecdotally,’ I won’t pretend to put numbers around it) that still take an “If it isn’t causing disruption in core systems, don’t fix it” mentality.

Ouch. We’ll be revisiting some of those in the future, I’m sure—when it’s listed as a vulnerability or breach somewhere.

I’m not a security professional. Because the vast majority of enterprises do not have dedicated security and even more don’t have anything close to enough security staff, I have done security as a part of almost every job I’ve taken—because it was what needed doing the most. Many, if not most of you, are in the same boat.

That said, I can tell when you are blatantly asking for a security incident. And running code known to be faulty or misconfigured to the point that it repeatedly crashes is deliberately asking for a security incident. “But it isn’t exposed to the Internet!” is only a valid rebuttal until an attacker gets inside the perimeter and uses your fault for something like privilege escalation. Then no one cares if it’s connected to the internet or not; they want to know how the attacker did it. And that’s on you.

So for those organizations in which speed has overridden common sense, let’s be very clear and to the point.

It is a best practice not to run crash-level faulty software.

Since you must not have one, write a policy that explains this and lays out a process and/or timeline to fix these problems. Then drive it home. Make certain it is known that this policy will be enforced. For that huge majority of my readers that don’t have the level of authority that “create and promulgate a policy” implies, convince those who do. Point out the issues to them in writing. “Notified in writing of faulty practices that could bite the company in the rear,” tends to get even the most unfriendly management to click into CYA mode and do something about it.

When we all watched those spectacular failures back in the day, I assumed that this was all about growing pains; you can do so much more with Agile/DevOps/cloud and/or Kubernetes that this type of thing would crop up and, eventually, get addressed. I still believe that. You all are still testing the boundaries and pushing the limits and making all of IT look good. It’s just going to hurt getting there sometimes. Fix the apps, make the policy, keep kicking butt and know you are killing it (as an industry. If you aren’t, stop laughing at my blanket compliment and fix yourself).

April 6, 2022
Researchers Find Privilege Escalation Vulnerability in GitHub Repos

Legit Security today revealed that it discovered a privilege escalation vulnerability in GitHub repositories that has since been remediated.

Liav Caspi, Legit Security CTO, said the company worked with GitHub to remediate the issue prior to disclosure. Legit Security researchers reported they found hundreds of GitHub instances rated with over 1,000 stars each that could be subject to the vulnerability.

Caspi said the company also reached out directly to most of those affected sites, including an instance of GitHub that is used to develop the open source Nginx web server that is employed across hundreds of millions of websites.

Cybercriminals could exploit a vulnerable build script to modify code or built artifacts that would result in software being shipped with code controlled by some other entity. The vulnerability could also enable access to sensitive secrets, such as keys, that are used to access cloud services or simply create a malicious pull request.

Legit Security researchers employed a set of risk assessment tools that are part of a larger software-as-a-service (SaaS) platform that enables them to apply security policies across their entire software development life cycle. Earlier this year, the company made available a free Rapid Risk Assessment tool to provide organizations with more insights into their software supply chains. Security research findings, along with other security best practices, are embedded within the policies that can be enforced via the Legit Security platform.

In the wake of a series of high-profile breaches, there is now more focus on the security of software supply chains than ever. Gartner estimated that 45% of organizations worldwide will have experienced attacks on their software supply chains by 2025, a threefold increase from 2021.

Despite those concerns, however, the rate at which new applications are being deployed and updated doesn’t appear to be slowing. Organizations are too dependent on software to encourage customers to slow down the development and deployment rate of applications. It will, however, take years for organizations to properly train developers to correctly employ security tools within their application development processes, otherwise known as DevSecOps best practices, to reduce the number of vulnerabilities that now routinely manifest themselves in production environments. The only practical alternative is to embed more tools that automatically discover vulnerabilities in code during the application development process.

Regardless of the DevSecOps approach, the ultimate goal remains to build more secure applications faster. That can only be achieved if there are more guardrails in place that prevent developers from inadvertently introducing vulnerabilities into an application. The more frequently applications are updated, the more likely it is that a vulnerability will be introduced. Each time those vulnerabilities are discovered after an application is deployed in a production environment, the more expensive they are to remediate. As the volume of vulnerabilities increases, it’s also only a matter of time before the sheer number of security issues that need to be addressed overwhelms both developers and security operations teams alike.

Application security, of course, has not always received the attention it deserves, but demands for increased application security can no longer be ignored.

April 5, 2022
Understanding SaaS Security for DevOps
As Software-as-a-service (SaaS) and DevOps adoption grew, new teams were formed to address emerging security challenges. Traditional solutions weren’t built to detect the new vulnerabilities in the cloud and created excessive noise for an already stressed pool of resources.

The combination of emerging zero-day vulnerabilities and an avalanche of false-positives ends up increasing security problems and slowing down DevOps projects. The good news is that recent developments in security and visibility are now increasing speed and improving visibility.

Gartner forecasted spending on public cloud services would reach $396 billion in 2021 and increase by 22% to reach $482 billion in 2022. SaaS applications based in the cloud have exploded with the market growing 18% each year; 99% of organizations will be using one or more SaaS applications by the end of this year.

What does this mean for security, especially for the security of personally identifiable information (PII) and business data in the enterprise? SaaS data includes, but is not limited to, customers’ sensitive PII and payment information; increasingly SaaS applications also house mission-critical enterprise information including product plans, patent information, business and operational processes and human resource records.

The extensive data held in SaaS applications presents huge security risks and costs for organizations globally. The average cost of a data breach exceeded $4.2 million, the most in the 17-year history of the IBM Cost of a Data Breach report, and nearly half of the breaches involved compromised PII, the costliest record type to lose, at $180 stolen record—an increase from $146 per record in 2020.

SaaS Offers New Ways to Do Business but Introduces Significant Risk

Salesforce is one of the most recognizable and widely used examples of enterprise SaaS software. Recently, analyst Vernon Keenan explained how Salesforce DevOps required guardrails. “Some companies go too fast when it comes to SaaS, DevOps and security, but smart developers and implementers will respect some basic guidelines to keep their product safe.”

The same is true of other SaaS software platforms and solutions.

General purpose application security testing solutions aren’t built for SaaS software environments, and often slow down DevOps processes as well as lack the necessary visibility into SaaS environments. Instead, the patchwork of tools must be replaced with a continuous integration and continuous deployment (CI/CD) approach. Specific steps include:
1. Check all local and remote libraries. Only checking configurations and access controls, which focus mostly on insider threats, misses application vulnerabilities from custom development or app downloads that could open up your SaaS services to external threat actors.
2. Carefully and routinely check third-party software libraries. If you are only testing source code and ignoring third-party software libraries, you are only securing half of your software application attack surface. CVEs are publicly reported every day on commonly used open source software libraries, showing attackers a direct path to compromise those key components. Running a software composition analysis (SCA) regularly to check all your locally bundled and remotely referenced libraries is a key step in achieving a secure software supply chain.
3. Don’t assume you’re protected from common vulnerabilities. Static application security testing (SAST) can often miss cross-site scripting (XSS) or SOQL/SOSL injection attacks on SaaS platforms.
By identifying security vulnerabilities faster and more accurately, new SaaS security tools can allow organizations to gain the promised benefits of DevOps with better visibility.
April 5, 2022
WhiteSource Offers Free Spring4Shell Vulnerability Tool

WhiteSource has launched a free command-line interface (CLI) tool that detects vulnerable open source Spring4Shell vulnerabilities (CVE-2022-22965) that are impacting Java applications built using the Spring development framework.

Susan St. Clair, director of product management for WhiteSource, said the WhiteSource Spring4Shell Detect tool is similar to the tool the company made available earlier this year to detect Log4Shell vulnerabilities in Java applications. It provides an exact path to direct and indirect dependencies along with how to find a fixed version of the Spring framework to accelerate remediation efforts.

Spring4Shell is yet another zero-day vulnerability that has been given a 9.8 severity score. As a result, DevOps and cybersecurity teams are now racing to update applications impacted by this vulnerability before cybercriminals can exploit it. The Spring4Shell vulnerability enables remote code execution (RCE), and the Java applications impacted employ versions 5.3.17 or 5.2.19 of the Spring framework and version 9 or higher of the Java Development Kit (JDK).

The vulnerability allows an attacker to remotely execute arbitrary code on the target server. It allows attackers to abuse a RequestMapping annotation that maps incoming HTTP requests into their appropriate handler functions. The vulnerable condition occurs when RequestMapping is used in conjunction with traditional Java objects as the handler parameter. Such an attack might allow access to all website internal data, including any database. It might also allow access to additional internal resources to gain more permissions or to pivot to other parts of the internal network.

It’s not clear how pervasively Spring4Shell might impact Java applications compared to Log4Shell vulnerability that affected a logging tool, but more security researchers are looking for RCE vulnerabilities within Java application environments. Organizations now will need to determine whether to maintain legacy applications that might be subject to more zero-day vulnerability discoveries or replace them with newer applications that are developed in a programming language that might be more secure. There is, of course, no guarantee a new application will be more secure than a legacy application, but the chances are good a modern application will have fewer vulnerabilities than a legacy application simply because the underlying programming tools and platforms are more advanced from a security perspective.

In the meantime, DevOps teams likely will be looking for instances of Spring4Shell vulnerabilities for months to come. DevOps teams that have access to a software bill of materials (SBOM) naturally will be able to find those instances more easily than organizations that don’t. However, the percentage of organizations that have SBOMs is still comparatively low. However, as zero-day vulnerabilities become a larger security issue, SBOMs are being implemented more widely as organizations review their software supply chains.

Whatever the path toward ensuring application security ends up being the level of scrutiny being applied to application development and deployment, processes will in the months ahead accelerate the adoption of best DevSecOps practices across organizations large and small, whether they like it or not.

April 4, 2022
Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Okta and Sitel under fire over Lapsus$ hack, Greenpeace and others call for bitcoin change, and Europe still hates encryption. (more…)

March 29, 2022