staging-devopsy.kinsta.cloud

Tag: devsecops

  • Survey Sees Little Progress on Securing Software Supply Chains

    Survey Sees Little Progress on Securing Software Supply Chains

    A survey of 1,750 IT security decision-makers published today found that, despite a series of high-profile cybersecurity breaches, nearly two-thirds (62%) of respondents have done nothing to secure their software supply chain. A full 64% conceded that an attack against their software development environment could not be stopped. And nearly three-fourths (71%) of respondents admitted their organization suffered a successful software supply chain-related attack that resulted in data loss or compromise of an asset, while 85% acknowledged a software bill of materials would also reduce the risk of compromise to a software supply chain.

    The survey, conducted by the market research firm Vanson Bourne on behalf of CyberArk, a provider of a privileged access management (PAM) platform, also found that 87% of respondents stored secrets in multiple places across DevOps environments, while 80% conceded developers typically have more privileges than necessary for their roles. Only 3% of respondents said their organization has a centralized secrets management platform to manage credentials used by applications.

    Organizations are also struggling to keep pace with the number of digital identities that have access to IT services. The average staff member has access to more than 30 applications and accounts, the survey found. However, 68% also reported non-humans or bots have access to sensitive data and assets, with machine identities now outnumbering human identities by a factor of 45, on average, the survey found. Less than half (48%) of respondents have any type of identity security controls in place for their business-critical applications.

    Even the threat of ransomware doesn’t seem to be having much of an impact. More than 70% of respondents said their organization has experienced, on average, two ransomware attacks in the past year.

    Brandon Traffanstedt, senior director for the global technology office at CyberArk, said it’s apparent organizations are accruing a significant amount of security debt that is not being proactively addressed. In fact, more than two-thirds of respondents (69%) said their organization has prioritized maintaining business operations over ensuring robust cybersecurity in the last 12 months. A full 99% of respondents said their organization had fast-tracked the adoption of at least one business/IT initiative over the last 12 months.

    In general, hybrid working (86%), the introduction of new digital services for customers or citizens (84%) and increased outsourcing (84%) are identified as the activities that are introducing the greatest risks. Specifically, the survey found credential access (40%) was the number one area of risk, followed by defense evasion (31%), execution (31%), initial access (29%) and privilege escalation (27%).

    Real-time monitoring and analysis to audit all privileged session activity; least privilege security/zero-trust principles on infrastructure that run business-critical applications and processes to isolate business-critical applications from internet-connected devices to restrict lateral movement are tied at 54% for the top three security initiatives organizations are planning to implement. The top three strategic zero-trust initiatives are workload security (52%), identity security (50%) and data security (45%), the survey found.

    Ultimately, the only way to address the current level of security debt organizations are incurring is by embedding functionality into DevOps workflows that automatically apply security policies and teaching developers to build more secure applications, said Traffanstedt. The former approach, however, may have a bigger impact more quickly, given the current level of cybersecurity expertise that currently exists in the developer community.

  • What DevSecOps for SAP Looks Like

    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.

  • Radware Embraces APIs to Improve AppSec Across Multiple Clouds

    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.

  • DevSecOps in Azure

    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.

  • The 6 Pillars of DevSecOps: Pillar One-Collective Responsibility

    The 6 Pillars of DevSecOps: Pillar One-Collective Responsibility

    With the increased interest in DevSecOps, the Cloud Security Alliance (CSA) and Software Assurance Forum for Excellence in Code (SAFECode) brought together a DevSecOps Working Group to identify and share best practices for the development and maintenance of a DevSecOps program. This working group identified and defined six focus areas critical to integrating DevSecOps into an organization; this article will focus on pillar one⁠—collective responsibility

    The Context of Security

    When we look at security historically, we find that it has often been relegated as a secondary objective when compared to other primary objectives like releasing features to market quickly. The rationale is that if we don’t release fast, our competitors will get ahead of us. Unfortunately, that mindset is fraught with security risk as evidenced by the rising number of vulnerabilities in our software. Malicious actors can take advantage of these vulnerabilities to breach critical systems and exfiltrate sensitive data.

    Let’s not be too hard on ourselves, however. Security in a DevOps world is not an easy problem to solve. As we continue patching vulnerable code, new flaws emerge just as quickly. In essence, the security landscape is dynamic and continues to evolve. Solving a complex problem like this requires diversity of thought. In other words, we need to include people with different perspectives in the security conversation. Essentially, we need to build a collective mindset rooted in security culture. Security then becomes a collective responsibility rather than the responsibility of a few people.

    Now that we’ve agreed on the importance of collective responsibility, the logical question that emerges is, “How do I operationalize collective responsibility?” Pillar one addresses this question. We need to bring together our security and DevOps cultures. No longer can we talk about security or DevOps. It has to be both. This means security must be considered and addressed at every point in the software development and operations life cycles. Extending this further beyond the technical domain, security is fundamentally tied to business objectives, not left as an afterthought or considered a mere cost drain.

    Building a security-supportive culture involves three broad phases:

    • Phase One: Gain executive support and engagement
    • Phase Two: Design an effective program
    • Phase Three: Sustain the program

    What Does Pillar One Mean for DevSecOps Practices?

    Pillar one reinforces the idea that security responsibility cannot be limited to a few people. Just as software development is no longer an exclusively technical activity, security is no longer a compliance activity. This has a profound impact on DevSecOps practices. Here are just a few areas that are impacted by this shift in mindset and responsibility:

    • People across software development and operations activities must now consider security requirements
    • Security tools can no longer run separately from DevOps pipelines
    • DevOps teams need to understand security and how it applies to their roles
    • Security teams need to translate high-level policies into clear, atomic security requirements that can be implemented and tested

    How is Pillar One implemented?

    Implementation of pillar one touches on structural issues aimed at removing silos. There are many possible ways to build cross-functional teams. One approach is to have security embedded inside DevOps teams. Another approach is to integrate security as a support structure for DevOps teams. In either case, given the limited number of security professionals, a security champion can help bridge the gap between DevOps teams and security teams. A security champion ensures that the software being built and deployed takes security into account. To achieve this, it is important to set up a security champion for success:

    • Security must be their primary responsibility
    • They must be viewed as the security expert in engineering teams
    • They are responsible for mentoring and training developers
    • They can own threat and privacy models
    • They must have clear goals that are aligned with the business

    Setting up a security champions program without a clear sense of direction can lead to a lot of wasted time and effort. Collective responsibility rests on teams being able to communicate across functional silos and a security champion is an exemplar of that mindset.

    Speed Versus Security

    We live in a world where the rate of software development and deployment outpaces traditional security practices. This has come at a cost. Balancing both speed and security is the new norm. The right balance is dependent on each organization. One thing remains the same, however, and that is culture. We need a culture that is supportive of security and views it as a collective responsibility. This takes intentionality. Organizations need to get their executives involved and make sure the program has relevant elements to drive a security culture and has a clear path to business value.

  • Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    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.

  • Understanding SaaS Security for DevOps

    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.

     

     

  • WhiteSource Offers Free Spring4Shell Vulnerability Tool

    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.

  • Fixing Spring4Shell Starts With Software Supply Chain Management

    Fixing Spring4Shell Starts With Software Supply Chain Management

    Spring4Shell is the latest call to action for radically improved software supply chain integrity. While Spring4Shell investigations continue, one conclusion is indisputable: We must holistically rethink the way we continuously inventory and manage the complex landscape of interrelated software and its sources.

    Whether or not Spring4Shell surpasses the breadth of impact of Log4j, there’s still massive potential for severe consequences to software and API security across the open source infrastructure, frameworks and application software stacks.

    That’s because, as we saw with Log4j, this attack could impact most enterprise Java applications globally. It seems the root cause is a vulnerability in the widely used, free, community-developed, open source programming framework Spring Core.

    The Spring framework is the foundation for most enterprise Java applications—as many as 74%, according to some data. Specifically, Spring serves as the foundation for enterprise Java apps so that teams can focus on application-level business logic without being locked into specific deployment environments.

    Spring Core’s ubiquity introduces significant potential for widespread impact due to its use across enterprise software, cloud services, third-party software and service products as well as internally managed software. This is another call-to-action to improve the way we approach software supply chain security and supply chain management. Thankfully, there’s already a place to start.

    Every infrastructure and software team can begin addressing this vulnerability by leveraging resources from The Linux Foundation’s Software Bill Of Materials (SBOM) project. The 2021 initiative included an SBOM readiness survey, a Generating Software Bill Of Materials training course and an SBOM generator tool based on the SPDX standard (ISO/IEC 5962:2021).

    The Linux Foundation’s SBOM contributions provided all of us a head start to begin addressing issues with software supply chain management. With widespread adoption, SBOM equips software projects and users to assess and address Spring4Shell as well as any other as-yet-unknown vulnerabilities and prepare us for what is undoubtedly a season of high-impact infrastructure software vulnerabilities.

    For more Spring4Shell resources, please visit: https://www.contrastsecurity.com/security-influencers/new-spring4shell-vulnerability-confirmed-what-it-is-and-how-to-be-prepared

  • Why Your Business Needs DevOps

    Why Your Business Needs DevOps

    One of the biggest headaches IT leaders face today is managing cross-functional teams to develop and deploy high-quality software faster. Not only does their work have to be continuous to stay productive, but there’s the need to save the business money, time and improve end user and customer satisfaction while fixing a seemingly endless parade of bugs.

    Without a robust DevOps process in place that benefits the entire organization, IT management and tech leaders often feel like they are chasing the impossible.   

    What is DevOps?

    DevOps is a set of practices that help you plan how both development (Dev) and operations (Ops) teams can work cohesively to deliver your company’s products and services, meet customer needs and stay ahead of your competitors. In short, it is a set of tools that leverages people, processes and technology to enable safer, faster handling of any IT software delivery initiative.  

    Yet, according to Gartner, as of the beginning of 2022, 75% of DevOps initiatives have not met these expectations because of inefficient collaboration, lack of buy-in from employees, trying to do too much too quickly and unrealistic expectations. For a methodology that is so critical to businesses today, it’s still surrounded by uncertainty and doubt. Let’s look at how you can make DevOps work for you and why it’s so important that you do so.

    Addressing Bugs

    Because detecting and addressing software bugs is a major priority of any IT department, disruptions need to be handled quickly and efficiently. This can only be done through immediate action and a tried-and-testing workflow in which all departments involved can act fast. The beauty of DevOps is that the process can be continuous rather than reactive and thus improve the quality of your software when deploying new features, as DevOps allows you to make changes rapidly. 

    Without DevOps, productivity is slowed or even brought to a halt which leads to an often-damaging customer experience.  

     Improving Customer Satisfaction

    A significant benefit of adopting DevOps practices is that it lowers the failure rate of new features while improving recovery time. The continuous deployment, testing and feedback loops ensure faster service delivery and happier customers. The development team can focus on creating superior products by automating the software pipeline while the operations team can improve business delivery. 

    Faster delivery of your products and services should not be a pipe dream. Those who understand and implement DevOps should feel confident they can stay ahead of the competition. 

    Improving the Security of Your Software

    DevSecOps builds on the DevOps pipeline to integrate security from the very beginning of the development cycle rather than at the deployment stage when flaws and vulnerabilities are more difficult and costlier to fix. Combining development, security and operations across your products and services will improve quality, security and your ability to meet client expectations. Building security into your pipeline seamlessly means bugs and other issues can be addressed more easily and remain almost unnoticed to the end users.

    DevOps and DevSecOps make this possible so that outdated security practices are not integrated into your software and don’t interfere with customer demand. So, if increasing customer satisfaction and positively impacting your bottom line by delivering high-quality, secure and effective software is on your business priority list, then implementing a DevOps process can not only save IT headaches but deliver better business outcomes.