devopsy.kinsta.cloud

Category: IT Security

  • Secure Software Summit: Measuring and Mitigating OSS Risks

    Secure Software Summit: Measuring and Mitigating OSS Risks

    Measuring and mitigating the security risks in open source software is becoming a major issue in the software development community. Attacks on open source software (OSS) are on the rise; open source supply chain attacks grew 650% in 2021—a staggering number.

    2021 and early 2022 saw significant attacks which impacted more than 1,000 organizations. The most prominent recent OSS attack was the Log4Shell vulnerability disclosed in December 2021. Attacks on the OSS supply chain and on OSS impacted nearly every single software organization on the planet. Everybody is scrambling to continuously patch systems as new vulnerabilities continue pouring in.

    To properly navigate this environment and keep our systems safe, we as a community need to understand the security risks of OSS and be better prepared to handle them, collectively and individually. 

    Open Source Risks

    There are a number of risks that make OSS more vulnerable without proper security measures. 

    OSS is Free; OSS Security is Expensive

    To start, we must recognize that open source software may be free to download and require no payment, but it comes with a massive security cost. 

    A significant portion of open source software is developed by volunteers in their free time. Most of the prominent open source volunteers actually have full-time jobs, and the code they contribute to projects like the Log4j logging libraries are written on nights and weekends; on their own time and not on the company dime. Not surprisingly, security isn’t high on their priority list. They don’t have the resources to invest in a secure development life cycle or have the time and bandwidth to maintain their code. This may mean that security vulnerabilities remain unaddressed for long periods of time, sometimes indefinitely. 

    All Bugs are Shallow, but There Aren’t Enough Eyeballs

    In software development, Linus’s law states “…given enough eyeballs, all bugs are shallow.” However, this is only true if those eyes are looking in the right place. In the case of open source, all code is open but there aren’t enough eyes paying attention to it to spot all the bugs. In addition, organizations may not consider the security consequences of their decision to consume a particular piece of open source software and adding it as a dependency. Dependency trees become more and more complex; harder and harder to monitor and secure, as you keep adding more third-party components to a core codebase. Each new dependency might bring additional nested dependencies—perhaps hundreds or thousands, depending on the size of the library added or the role it plays in the application architecture. For example, the Kubernetes project—one of the most successful and widely adopted OSS projects—has several thousand dependencies, many of which have additional secondary and tertiary downstream dependencies. 

    So Much Code. So Many Choices. Not all are Good.

    The beauty of the open source ecosystem is that there is a solution for everything. The problem with the open source ecosystem is that there’s not just one solution, but several dozen. For example, if you need a JSON parser for your application, there are several to choose from. If your application is running a critical service or infrastructure, then picking the right JSON parser—one that is secure and comes from a responsible project or maintainer—becomes very important. A JSON parser will serve as a critical component for your application, so it will impact the security of your entire system. If you chose the wrong JSON parser, you might pay a big price down the road in security risk and subsequent breaches. 

    Proposal: An Entry Gate Security Risk Assessment

    One potential solution to enhance OSS code security is the creation and implementation of a security risk assessment gate as part of your OSS ingestion pipeline. Putting this process in place will help you understand whether consuming a certain piece of software is high risk and avoid software that does not meet your risk criteria. 

    Here is an example of how this might work. Consider five different JSON parser libraries in GitHub, all of which have a high number of stars and appear to be highly rated. How can we assess the risk of these libraries and quickly and easily eliminate ones that are too risky? One of these JSON libraries is hosted under a user account. Most of the commits are done by a single developer without reviews. This alone indicates that using this library in a critical system presents a high risk. This lone developer could commit malicious code without review. The maintainer’s token access could be leaked, allowing attackers to insert malicious code. The developer might also turn over committer control of their library to a malicious actor without notifying users (who might not pay attention to the notification anyway). Identifying this risk required no more than a few minutes of review of the repository and cost little in time or effort. 

    A Broader View of Security Posture for OSS

    More broadly, we need to understand the full security posture of an organization or developer and their open source code prior to adding it to critical systems. Because OSS is a complex ecosystem and many pieces of OSS are complex, the risks they generate are similarly complex. Our traditional, myopic view of these risks is that we just need to find all the security vulnerabilities in our codebase and fix them. This does not resolve all risks and may lull us into a false sense of security.

    We need to understand the full comprehensive security posture of an open source project. That involves understanding a broad range of risks beyond code vulnerabilities. Here are some of the key risks to consider beyond ensuring that your codebase is well-secured and patched. 

    Supply Chain Attacks on the Build Pipeline

    Attacks like SolarWinds and CodeCove taught us that supply chain risk is a very big deal and that tools are just as much at risk as code. Attackers have found it much easier and much more reliable to attack build pipelines, rather than finding vulnerabilities in code.

    Security Risks Revealed by Continuous Security Testing 

    Continuous security testing is critical to maintaining the security of a codebase. There might not be code vulnerabilities today, but as developers continuously modify code and iterate on applications, vulnerabilities may be introduced. This can mean testing code as part of the CI/CD process with every new code push. For example, we have found numerous critical bugs in OpenSSL libraries. All were caught on a master or main branch and never made it to a production release. 

    Project Maintenance and Capabilities

    One of the really big risks with open source is the quality and frequency of project maintenance. Issues raised may not be addressed in a timely fashion. Maintainers of a project may have a long backlog of issues, indicating that they are not actively maintaining a project. It is not uncommon for critical open source projects used in millions of applications and comprising a significant dependency to the global software supply chain to not have been updated in a year or more. In addition, maintainers of OSS projects may not know how to respond to security incidents and fix security vulnerabilities. This is particularly true if the maintainers do not work at a large organization, do not have cybersecurity or secure development experience or have never suffered through the toil and trauma of addressing a major vulnerability in their code on short notice. 

    Tools for Measuring and Addressing Supply Chain Risk

    A number of efforts are underway to create free tools to help developers and application security teams better measure and address supply chain risk programmatically and analytically. 

    SLSA—Supply Chain Level for Software Artifacts

    As a tool to help organizations better address software supply chain risks, Google created a novel framework that we call Supply Chain Level for Software Artifacts (SLSA). The project has been underway at Google for more than a decade and has been open sourced as part of the OSSF. Contributors include VMware, Citibank and Datadog, among others. Google hopes to standardize SLSA and make it an industry benchmark for evaluating supply chain risk. Right now, SLSA is focused primarily on build process risks but the hope is to expand it in the near future to other areas, such as vulnerability and maintainer risks.

    OSS Security Scorecards Project

    In order to scale the process of assessing, identifying and mitigating risks in OSS, we need robust automation. In 2020, as part of the OSSF, Google released a new project called Open Source Security Scorecard. The project aimed to automate the analysis and trust aspect when evaluating the security posture of open source code. Further, the Scorecards can provide specific security recommendations. The Scorecard process can incorporate many other automated tools, including checking against vulnerabilities using the Open Source Vulnerability (OSV) database and running dependency checks using open source dependency trackers like Dependabot. The scorecards project also makes it easier to report new vulnerabilities and get those to the right people in a project. 

    Conclusion: What is not Measured is not Mitigated

    No one denies that OSS has become crucial to the vast majority of applications running the world’s technology foundation. The span of OSS continues to grow, as more and more languages and frameworks emerge and specialization increases. No one wants to reinvent the wheel and rewrite fresh code to perform the same tasks with every new application. The model of reuse, dependency and distributed software development works and speeds innovation. That said, the open source community and the supply chain used to build OSS need a more rigorous approach to reducing risk. Given the scope of the problem, automation and standardization are helping to scale toward the stated goal. We are in the early stages of creating the tools and infrastructure to automate the risk identification, measurement, assessment and mitigation processes. Security frameworks like SLSA and new processes like entry gating new OSS code with security scorecards will direct organizations down that path and move us toward a more secure open source future.

    About Secure Software Summit
    The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.

    https://go.shiftleft.io/secure-software-summit-2022-replay

     

  • Secure Software Summit: The State of OSS Supply Chain Security

    Secure Software Summit: The State of OSS Supply Chain Security

    The open source software (OSS) supply chain is under attack. As evidenced by the recent Log4Shell vulnerability, the OSS supply chain is increasingly a focus for attackers seeking to exploit weak links in security. A number of research reports have recorded a significant increase in so-called ‘next-gen software supply chain attacks‘ over the past decade. These attacks look to compromise key links in the software supply chain including source code, build systems, CI/CD tools and code testing tools, among others. Next-gen attacks are happening across all languages, all types of software and are increasing in their frequency. Common forms include typosquatting, malicious code injection and tool tampering (like the CodeCov incident). In 2021, 64% of organizations reported they were affected by software supply chain attacks, according to container security company Anchore. 

    The increasing wave of next-gen attacks has driven new regulations mandating specific steps to inventory and make more transparent the content of software applications and the software supply chain. Specifically, executive order 14082, issued by U.S. president Joseph Biden, mandated a long list of security practices, including the inclusion of a software bill of materials (SBOM) with every application run by the U.S. federal government. The National Institute of Standards and Technology (NIST) is creating reference architectures and templates for application security as a result of the executive order. In other words, software security regulations will likely impact every company that produces code or sells products running on code (including SaaS products). 

    To be clear, some of the problems experienced by the OSS software supply chain are not exclusive to open source. The recent supply chain attacks on Microsoft Exchange Server and the SunBurst attack on the SolarWinds network management tool targeted proprietary code bases. That said, OSS is produced and maintained very differently than proprietary software. This does result in some unique risks. Here, we will cover those risks as well as some promising initiatives underway to address them.  

    Why Is the OSS Supply Chain A Juicy Target?

    There are two primary reasons OSS supply chains are a tempting target. One is its omnipresence and the other is its weakness. It is not an exaggeration to say that OSS is omnipresent. According to Sonatype, 98% of all codebases contain OSS. This is likely an underrepresentation. You simply cannot build code from scratch today without using OSS components. It is too labor-intensive and expensive. The ubiquity of OSS makes the supply chain that creates, distributed and manages it an obvious target. At the same time, that widespread use translates into an increasing burden on companies to maintain, update and patch all OSS dependencies in their applications. 

    This is an impossible task; it is far easier to insert OSS code to solve an immediate problem than to, over time, make sure that code is updated and not vulnerable. For this reason, Sonatype estimated that 92% of all applications contain outdated or vulnerable code. We have seen the impact of this inability of organizations to maintain their OSS code through attacks like the one perpetrated against Apache Struts software run by credit reporting company Equifax, a breach that exposed the sensitive personal and financial information of hundreds of millions of Americans.  

    In recognizing that OSS is a fruitful channel for attacks, attackers have focused more specifically on the supply chain because it is often the weakest link. Elements of the supply chain reside in the gap between responsible organizations and may be less strictly policed or less actively secured. Continuous integration/continuous deployment (CI/CD) tools, OSS libraries that can easily access other systems, package managers and open source developer tooling are all components of the supply chain that are widely used but which are often the sole responsibility of many part-time maintainers who write and maintain code as an unpaid avocation. 

    OSS-Specific Challenges

    The three key benefits of OSS each create unique security and supply chain challenges. Specifically, OSS is open, free and transparent. 

    The Two Sides of Open

    Linus Torvalds said that many eyeballs make all bugs shallow. To a degree, this is true. But what if those same eyes are looking for bugs to exploit rather than fix? Not everyone on the internet is nice and many seek to exploit the fact that anyone with a GitHub account can contribute code to critical libraries. This attracts a lot of great contributors, but also a lot of bad actors and bad behavior. 

    That behavior is often hidden or delayed. For example, we often see bad actors ask to contribute to projects or libraries run by single maintainers that are relatively popular and used by big applications. Often, maintainers struggle to keep up with the demands of these projects. A bad actor will offer to help, submit a handful of good PRs and gain commit privileges to the repository. At this point, the bad actor will then stealthily insert malware, such as a cryptojacking script. 

    Free Puppy. Not Free Beer. 

    Free is a good price. There are no purchase orders. This makes it super easy to use. Free also serves as a great distribution strategy. However, sometimes free is not worth it. If an organization depends on an application and it becomes critical, they might require fast patching, better compliance and official support relationships. Free OSS comes with no guarantee, and this can be a major liability. An application’s maintainers might be writing the code and applying fixes in their spare time on weekends because they already have a full-time job. In fact, research has shown that a significant percentage of the critical software powering the internet is maintained by volunteers; this was the cause of the Heartbleed vulnerability in the OpenSSH encryption libraries. 

    Free code also may not be updated for years. If a vulnerability is disclosed, you may not be able to get permission to merge fixes you write. If the code is abandoned and the author no longer checks comments or requests, then you are stuck and may have no choice but to fork the project. A hard fork on short notice can cause chaos and its own problems. This is what happened with a popular Golang library called JWT Go, which made its way into dependency trees across the Golang ecosystem. JWT Go was even included in Kubernetes, one of the most popular and important open source projects. When a vulnerability to JWT Go emerged, everyone realized the maintainer had abandoned it. Multiple forked versions emerged with different patches for the same bug. Chaos ensued. 

    It is a common refrain to ask companies to fund volunteer maintainers. There are numerous programs for this, including GitHub Sponsors, Open Collective and Tidelift. These programs are helpful but not sufficient. You can’t just hand people a small amount of money and get more secure code and professional-grade maintenance. Even if you offered full-time salaries, it might not translate into well-supported, secure code. 

    The Illusory Benefit of Transparency

    The transparency of OSS is real, but the idea that this code is getting audited and reviewed constantly is an illusion. Yes, the source code is distributed and open. But the sheer quantity makes it impossible to review all the code you use. If you are using millions and tens of millions of lines of code, you don’t have time or sufficient eyeballs. Even if you are spending considerable resources on code review, it is still easy to miss problems and vulnerabilities and relatively simple for malicious contributors to projects to hide malware or other bad inclusions. Reviewing the source code also does eliminate all risks. When most OSS code is consumed, it is running as a package compiled by another entity or developer. 

    Further, there is no guarantee that the contents of the package comes from the same source code you audited. We have actually seen this attack often with package repositories like npm and Maven, where malicious actors insert tampered builds or take over packages and insert code that is not listed as part of the package. 

    The CodeCov incident is one of the more recent and egregious examples. This free service for checking the code coverage of unit tests used BASH script running inside of a CI server for installation. The script was compromised and attackers inserted malware that could steal code secrets and export them. Those secrets might be tokens used to publish packages in npm or Maven and exposing those secrets allowed attackers to then compromise those packages. In another example, a PHP server managing source code distribution for the PHP project was compromised and multiple commits injected malicious code into the source code repository. The incident was caught quickly, but it demonstrated how attackers could tamper with source code directly, bypassing code review and security processes.  

    But All is Not Lost

    Innovative efforts to better secure open source and its supply chain are gaining momentum. The SBOM is gaining acceptance and it is getting easier to automatically generate SBOMs from CI/CD pipelines or build systems. A new initiative to make it easy to cryptographically sign code, called Sigstore, aims to remove barriers to code signing; ubiquitous code signing would make it much harder to compromise the supply chain by attacking the source code provenance problem at its root. Lastly, the Open Source Security Foundation has garnered tens of millions of dollars in funding from major technology companies and is in the process of spinning up mechanisms to issue grants and otherwise provide a more robust financial support mechanism for OSS. These developments point to a brighter future where the OSS Supply Chain is far more robust and companies can more easily audit, track and trust all the OSS dependencies in their applications and the full supply chain that moves OSS code from developer boxes up into production environments. 

    About Secure Software Summit
    The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.

    https://go.shiftleft.io/secure-software-summit-2022-replay

     

  • Google Focuses on Enterprise Cloud With Mandiant Acquisition

    Google Focuses on Enterprise Cloud With Mandiant Acquisition

    Thomas Kurian became the CEO of Google Cloud Platform (GCP) with a modest mandate: Turn Google Cloud into an enterprise cloud platform behemoth. Easy, right? By 2019 “Google” was already a verb because of its search engine dominance and the company’s revenue was north of $136.8 billion. So, why have I been closely tracking Google Cloud’s progress on winning enterprise cloud business? Let’s back up.

    When Kurian left Oracle and joined Google, the company was an extremely successful advertising company. At the time, over 85% of Google’s revenue came from advertising. The search engine, email service and lightweight office productivity apps all served the ultimate goal of keeping eyeballs on Google sites so that users could be served more advertisements and increasingly more personalized ads based on a user’s Google interactions.

    If You Build it, Will They Come?

    Enterprises Require More Than Just Technology From Their Cloud Providers

    Google clearly has the scale, tools and technical expertise to provide businesses with what they need from a cloud vendor. When Kurian left Oracle, he was one of the highest-paid technology executives in the world (according to Oracle, his 2017 compensation package was around $36 million). So why would Google hire Thomas Kurian? Because enterprises require their technology and services partners to have more than just great tech. When advising enterprise clients, the following are the top three topics that come up when discussing the selection of a cloud vendor:

    • Industry Expertise: For the enterprise, understanding industry nuances is critical. I recently talked to an executive at a large airline company that fired their large, publicly-traded technology services company because the partners and the services company didn’t truly understand the airline industry. They weren’t using the right terminology and didn’t understand the business pain points.
    • Predictability: Why have large enterprises been hesitant to go all-in on the cloud? They need predictable technology. That doesn’t just mean “stable;” it means that costs, security, usability and service levels must all be predictable. Why, for example, is the mainframe still critically important for many enterprises? Because it is predictable and secure.
    • Ecosystem: Clouds can’t live in isolation. Cloud vendors must have an ecosystem to support enterprise client needs. My number two cloud prediction for 2022 is that we will see an increase in industry-specific ecosystems. Amazon Web Services (AWS), Microsoft Azure and IBM Cloud all have cloud ecosystem strategies focused on financial services.

    Thomas Kurian is well aware of the need to play well with other cloud providers and enterprise cloud providers. In fact, the widely held belief is that Kurian left Oracle because he and Oracle CEO, Larry Ellison disagreed on Oracle’s multi-cloud strategy—Kurian wanted Oracle’s packaged applications to be available on other vendors’ cloud platforms.

    What Does the Mandiant Acquisition Mean for Google?

    It’s clear that Google Cloud is focused on the enterprise. Google has no shortage of DevOps, data, machine learning and artificial intelligence tools to satisfy developers and data scientists. However, what Google needs are more features that enterprises expect from a cloud partner.

    Google Cloud isn’t new to cybersecurity—the company has been securing its own cloud since its foundation. In addition, the company has been gaining enterprise traction with Google Workspace and Gmail and the security around these SaaS offerings is paramount.

    By acquiring Mandiant, Google Cloud can more closely partner with cloud customers throughout the entire life cycle: From code creation (through a combination of Google’s existing Google Chronicle tools) through testing, threat detection and advisory work around incident response.

    My Analyst View

    The debate around security and the cloud isn’t even close to being resolved. Many will tell you that cloud vendors invest millions upon millions of dollars more than any other company in the cloud. It’s imperative that cloud vendors don’t experience infrastructure or SaaS security breaches. However, security continues to be a roadblock for cloud adoption—and, most importantly, enterprise cloud adoption. While every enterprise is doing some work in the cloud, many are still reluctant to move critical workloads (especially their sensitive data) to the cloud.

    Google Cloud should use Mandiant as the bedrock on which its enterprise cloud security business is built. Rather than having piecemeal parts and partners, businesses want their cloud providers to have opinionated frameworks and best practices. Mandiant has some of the best security minds in the industry and can help Google Cloud customers create secure instances. I expect Google Cloud to provide ready-to-provision cloud environments tailored for specific regulated industries by leveraging Mandiant’s expertise. Of course, customers aren’t going to want to necessarily adopt everything that Google Cloud suggests, and customers should be able to swap out components. However, many businesses are already overwhelmed with the number of cloud partners they have to engage with to create a secure cloud environment.

    What Will Microsoft and AWS Do?

    I expect AWS and Microsoft Azure will focus their attention on building out enterprise-focused security offerings. I recently wrote about why it made sense for Microsoft to purchase Mandiant. My general feeling was that Microsoft had many security offerings—ranging from simple consumer-grade virus scanning to enterprise offerings—but that the company lacked a cohesive enterprise security strategy. I still believe Microsoft needs to clearly define its enterprise security assets (and more coherently group them together) either through a reorganization and/or an acquisition. Like Microsoft, AWS has hundreds if not thousands of security offerings and partners. Although AWS is the cloud leader, the company is well behind Microsoft and Google in defining its cloud security strategy. The company needs to outline its enterprise cloud strategy, and cybersecurity needs to be one of the linchpins of that enterprise strategy.

  • What to Expect When Transitioning to DevSecOps

    What to Expect When Transitioning to DevSecOps

    How do you ensure your DevOps pipeline is secure? Does DevSecOps protect you against serious breaches or is it just a way to allay the concerns of stakeholders about security in DevOps?

    A data breach can cost an average of $3.92 million USD, as per IBM’s study Cost of a Data Breach. In this report, health care was found to be the most expensive industry, with breach fines averaging $6.45 million USD.

    While DevOps delivers on the promise to increase the rate of delivery, the traditional CI/CD framework does not emphasize security. For the sake of speed, misconfigurations and known vulnerabilities may be allowed to pass through the development pipeline to production. 

    Security and testing are generally a low-priority activity, which means these vulnerabilities are fixed retroactively. This takes more time, effort and money. With rampant, unverified integration of open source tools, you open up the software to attackersthat could compromise the security of your apps, systems and users’ data.

    DevSecOps is an upgrade to DevOps, allowing you to deliver security and compliance testing continuously. These checks get integrated within the CI/CD pipeline to enable the delivery of more secure code faster.

    From DevOps to DecSecOps: What to Expect

    The automated nature of DevOps delivers several benefits that enable teams to realize the true power of DevOps as silos break and delivery rates skyrocket.

    As DevOps practices span the entire delivery pipeline, it provides the necessary mechanism to deliver audit, compliance and security requirements along with speed and efficiency. 

    There are many benefits of upgrading from DevOps to a dedicated DevSecOps practice, and they are important to understand before you embark on that journey.

    1. No Restrictive Access Control Policies for Developers

    Access to infrastructure assets must be strictly controlled and monitored to enforce requisite security measures. This means approval gates, secure configuration parameters and other security measures.

    With DevSecOps built into the pipeline, these access controls can be automatically applied. This enables on demand access to infrastructure resources for the team and reduces their dependence on factors outside the team. 

    For example, many organizations have started deploying internal DevOps teams that enable automated access to a shared pool of deployment processes, tools, repositories, workflows, etc. 

    This team is usually separate from the IT team but enforces security mechanisms with the same rigor. It ensures that access to all the infrastructure instances required by development, QA or production is automatically tracked, monitored and controlled as per the guidelines. Additionally, inconsistent processes or misconfigurations are also controlled.

    Often called the shadow IT team, the idea of this team is not to circumvent the IT department but to create an additional team that matches the agility of the DevOps team. 

    2. Seamless Security and Compliance Testing

    Traditionally, security and compliance testing happened all at once at the end of the release cycle close to the release date. This typically meant that a large spreadsheet of issues is sent to the development team to be fixed immediately, since maintaining a consistent release velocity is the key to DevOps success. 

    This requires the development team have at least one dedicated resource to work on those issues. When metrics are tracked, to no one’s surprise, this method resulted in negative impacts on the velocity of the next release cycle.

    DevSecOps applies all the security and compliance checks in batches. So, testing for security and compliance is shifted left and spread out across the pipeline.

    This makes the security feedback loops shorter and more frequent, thus aligning security and compliance testing with the DevOps philosophy. As more secure code is committed every time, the possibility of security and compliance errors reported by the QA team is minimized.

    A second, more personalized approach is using the integrated development environment (IDE) itself to take security and compliance checks to the developers. With regular and automated security and compliance baked right into the development process, this process is sped up considerably and the development team becomes self-reliant.

    3. Overcoming the Risks Associated With Open Source Software

    The 2019 State of The Software Supply Chain report from Sonatype showed that, on average, 85% of the codebase among modern applications uses open source components. While open source components enable innovation, they also come with considerable security risks. As more of these open source tools are added to the software supply chain, it increases the risks on the cybersecurity front.

    The same report showed evidence to back up the need for greater open source software security checks and processes. Companies that managed their open source components released 55% less vulnerable components than those who had no verifiable open source management process.

    While many of these open source components released frequent patches, it is also important for the DevSecOps team to step in and regulate the open source components. Some of the ways DevSecOps teams can do this are:

    • Create a formal component management plan which makes sure that when employees leave, the practice doesn’t go away with them. Having a documented plan lets you look at the bigger picture of your pipeline and find vulnerable components that may be skipped without a formalized process. Incremental improvements to this plan are also possible if it’s well-documented.
    • Use scanning tools like Gemnasium and Snyk that help regularly check for vulnerabilities.
    • If vulnerabilities are detected or reported in a component, look at either updating or replacing the component.
    • Enable quick approval for new open source software. Alternatively, prepare developers to test new components using security and compliance checklists.

    4. Overall Cost Reduction and Acceleration of the Delivery Rate

    An integrated security and compliance framework in DevOps prevents breaches and guarantees faster recovery when breaches do happen. As developers don’t have to set aside a large chunk of time to work on security and compliance violations, this shortens release cycles and ensures more secure code at the same time. 

    The fewer breaches you identify and fix, the more money you save on overcoming security disasters. 

    5. Automated Compliance Reporting

    DevSecOps automates your security and compliance tests and it also logs and documents all the tests. DevOps automation platforms collect large amounts of information for the build, test, integration and deployment phases. This data can be used to create an end-to-end audit trail without any manual intervention or extra time spent scouring through various tools to prepare compliance reports. 

    A fantastic advantage of DevSecOps is the complete traceability from day one and automated compliance reporting. DevSecOps also focuses on the automation of testing, allowing you to deliver a secure development framework on a continuous basis.  

    DevSecOps is the Future of DevOps

    The rapid release velocity DevOps enables is not without its disadvantages. In particular, the unchecked use of open source tools in the pipeline can expose your applications and systems to many known vulnerabilities, increasing the probability of a breach. Combined with a general lack of focus on security, this is a recipe for an expensive security incident. 

    To counter this, DevSecOps radically transforms the pipeline by shifting security and compliance testing left. Developers check the code before every commit. With fast feedback loops, they fix any reported vulnerabilities along with other errors in the app. 

    With DevSecOps, compliance and security checks are not done all at once; instead, developers chip away at vulnerabilities and security flaws with every release.

  • IBM ‘is Ageist and Sexist’ | IBM Mainframe-aaS | IBM Vaccine Mandate

    IBM ‘is Ageist and Sexist’ | IBM Mainframe-aaS | IBM Vaccine Mandate

    Think! Welcome to Big Blue Week here at 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: IBM’s employment practices scrutinized, IBM z/OSaaS breaks cover, and IBM encourages staff back to the office.

    1. ‘Dinobabies’ and ‘Dated Maternal’ Workforce Woes

    First up this week: IBM’s defense in an employment age discrimination lawsuit looks to be shredded. Internal emails “appear to show high-level discussion about paring the ranks of older employees.”

    Analysis: Not a good look

    According to one of the plaintiff’s lawyers, unnamed “top IBM executives were explicitly plotting with one another to oust older workers … to make room for millennial employees.” On the face of it, they seemed to be doing the polar opposite of the Age Discrimination in Employment Act.

    Noam Scheiber: Making ‘Dinobabies’ Extinct: IBM’s Push for a Younger Work Force

    Top IBM executives were directly involved in discussions about the need to reduce the portion of older employees … sometimes disparaging them with terms of art like “dinobabies.” … Documents made public by a Federal District Court … show executives discussing plans to phase out older employees.
    …
    The newly unsealed documents, which quote from internal company emails … show top IBM executives specifically emphasizing the need to thin the ranks of older workers and hire more younger ones. [One] email refers to IBM’s “dated maternal workforce,” an apparent allusion to older women, and says: “This is what must change. They really don’t understand social or engagement.”
    …
    Adam Pratt, an IBM spokesman, [claimed,] “IBM never engaged in systemic age discrimination.” [He] said that some of the language in the emails “is not consistent with the respect IBM has for its employees” and “does not reflect company practices or policies.”


    Yikes, ageism and sexism? Experienced staff are valuable, says MrBanana:

    I did some time at IBM [and] remember being invited to a meeting with a new group, headed by a new “thinker,” who had something to present to myself and a colleague. We walked past the foosball table to the meeting room. Naturally the room had no chairs, and was covered in multi-coloured Post-it Notes. Once they had gone through their mood boards and the non-linear presentation of this new idea, I turned to the other old geezer in the room. “Didn’t we look at something like this 8 years ago?”

    “Yeah, we worked out that compute power just to run the UI for one session wouldn’t be available for a couple of decades.” The children were somewhat disappointed, and (fortunately) we were never asked back to their romper room.


    But experience can be both a blessing and a curse, learned aahortwwy:

    I experienced both sides of this in five years at a company in hypergrowth. … I learned so much at that job: … In year 1, I was determined to accomplish X and ignored the skeptical comments of some colleagues who’d been at the company longer than me. I failed and wasted some time. In years 4 and 5, new colleagues were determined to accomplish X and ignored my skeptical comments.

    2. IBM Wazi as-a-Service Confusion

    “Mainframe” is not a dirty word. It’s secure, vertically scalable, and it put the VM in VMware. Now, what IBM Wazi did for on-prem LPARs, Wazi aaS promises to extend to hosting z/OS instances.

    Analysis: Mainframe-as-a-service reinvented

    Mainframes and cloud-native DevOps need not be incompatible. To modernize legacy apps using hybrid cloud instances for dev/test—and even prod—can be a big productivity boost. But isn’t it weird that IBM spun out its mainframe-as-a-service zCloud offering only a few months ago?

    Mike Vizard: IBM Shifts Mainframe App Testing to the Cloud

    While many workloads over the years have been migrated off mainframes or simply retired, the applications that run on z/OS today are still among the most mission-critical that organizations run. … IBM this week revealed it has added the ability to set up testing environments on the IBM Cloud for z/OS mainframe applications.
    …
    IBM plans to make IBM Wazi as-a-Service (Wazi aaS) for z/OS generally available in the second half of this year, [which] will enable DevOps teams to self-provision an instance of a z/OS virtual server on a secure private space running on IBM Cloud. … At the same time, it will become easier to modernize mainframe applications by making them more accessible to other applications via a set of secure APIs … using a cloud-native set of DevOps tools that run in a Kubernetes environment.
    …
    Modernizing mainframe applications is a less complicated endeavor than migrating them. The challenge is that building, deploying, maintaining and securing all the APIs required to do so represents a significant amount of effort.


    OK, boomer, why are we talking about 1960s mainframes on devopsy.kinsta.cloud? Here’s ArchieBunker:

    Mainframes are different beasts altogether, almost alien when you compare them to PC hardware. You have binaries written for the S/360 system in the 1960s? Good news you can still run them natively without a recompile.

    You think virtualization and containers are a hot topic? IBM was running multiple OS instances inside a VM in the 1970s. … The engineering is incredible.


    But z/OSaaS? It’s déjà vu time for Beleagured Greybeard:

    “Cloud Managed Services for z” AKA “zCloud” has been around for over 10 years. … IBM offloaded it with the Kyndryl spin, so its odd that they now want to re-invent it.
    …
    If it’s a strategic platform, why didn’t they hold onto it instead of spinning it off to Kyndryl? Sounds like yet more daft leadership decisions.

    3. IBM’s Return to Work Plan has Vaccine Mandate

    IBM wants to “keep employees safe” as they return to office work after being fully remote. In practice, this means a vaccine mandate.

    Analysis: IBM Digital Health Pass is divisive to vocal minority

    Although there are exemptions on medical or religious grounds, IBM has promised to place dissenters on unpaid leave. As you might expect, the policy has a few employees up in arms.

    Cassie Werber: How Salesforce, IBM, and HSBC are approaching return to work

    When the pandemic hit, and IBM moved 95% of its workforce to fully remote, it was pleasantly surprised to discover no drop in productivity. … Still, they planned to return to offices.
    …
    The company saw this as a way to keep employees safe. … One example … is its development of the IBM Digital Health Pass as an alternative to vaccine cards or paper vaccine certificates, which they use to make sure all the staff that come into their offices are vaccinated.
    …
    Arvind Krishna, IBM’s CEO, meanwhile came up with what he called the IBM Work From Home Pledge. [It] included commitments to flexibility, kindness, sensitivity to family, setting boundaries, and acknowledged video fatigue. It concluded with a commitment to “be connected.”


    Tricky to “be connected” if you’re not allowed back in the building. Anne D’Innocenzio, Heather Hollingsworth, Tali Arbel, Mae Anderson, Ken Sweet, Matt O’Brien and Dee-Ann Durbin:

    IBM software engineer Justin Albano said his company recently notified employees that it would be revoking badge access to workers who aren’t vaccinated or haven’t proved that they are. “We’re not able to enter an IBM office at this time,” said Albano.
    …
    He said some workers have successfully sought religious exemptions but “my thought process was I shouldn’t have to explain to my company my faith” to get out of a policy that’s “immoral in its foundation.”


    What’s the alternative? With a perspective, it’s Chris Haney:

    Or, get the vaccine. Protect yourself and the people around you. You people really are detached from reality.

    The Moral of the Story: Those who know do not speak; those who speak do not know.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Marcin Wichary—cc:by; leveled and cropped (ask your parents)

  • Linux Foundation Survey Sees Rise in SBOM Use

    Linux Foundation Survey Sees Rise in SBOM Use

    A global survey of 412 organizations published today by the Linux Foundation found nearly half of respondents (47%) producing or consuming software bills of material (SBOMs), and more than three-quarters said they expected to produce or consume them in 2022.

    SBOMs have become a bigger area of focus in the wake of a series of high-profile software supply chain-related breaches. The breaches involved application components compromised by malware that had been surreptitiously inserted during the application development life cycle. The Biden administration has gone so far as to issue an executive order requiring all agencies to provide SBOMs for all the commercial and custom software they use, but as of yet a deadline for compliance with that order hasn’t been set.

    In general, the Linux Foundation survey found that a large percentage of respondents (82%) are already familiar with the term SBOM. Respondents cited various benefits of having an SBOM, including making it easier for developers to understand dependencies across components in an application (51%), making it easier to monitor components for vulnerabilities (49%) and making it easier to manage license compliance (44%).

    However, the survey also makes it clear there is much SBOM work to be done. A full 62% of respondents, for example, are looking for better industry consensus on how to integrate the production/consumption of SBOMs into their DevOps practices. Respondents also cited a need for consensus on the integration of SBOMs into their risk and compliance processes (58%).

    More than half (53%) also said there is a need for better industry consensus concerning how SBOMs will evolve and improve.

    The survey also makes it apparent that organizations are more aware of the role SBOMs play in securing supply chains. A full 80% of organizations are aware of the White House’s executive order on improving cybersecurity, with more than three quarters (76%) considering making changes as a direct consequence of the order. Overall, the survey found the top consideration organizations focus on when evaluating open source software is security.

    Stephen Hendrick, vice president of research at the Linux Foundation, said 2022 is likely to be remembered as the year of the SBOM. There are several standards for building SBOMs, including an open source software package data exchange (SPDX) specification backed by The Linux Foundation and the Joint Development Foundation that is now recognized as the ISO/IEC 5962:2021 international standard. There is also CycloneDX, a lightweight SBOM standard based on an open source project that originated via the Open Web Application Security Project (OWASP) community and a software identification (SWID) standard for tags that some organizations use to create SBOMs.

    SBOMs are, essentially, a tool for listing the components that make up an application and are used inconsistently. However, when a critical vulnerability is discovered, they can sharply reduce the amount of time required to discover all the software components that need to be remediated. The challenge is, with the rise of containers, it has become much simpler to rip and replace software components in a way that may not always be reflected in the SBOM. Hendrick said in time, advances in technologies such as machine learning algorithms should make it easier to instantly reflect those changes in an SBOM.

    Regardless of approach, it’s apparent DevOps teams, like it or not, are about to be held more accountable for the provenance of every component employed across their entire application portfolio.

  • Securing Software with Intelligent Pipelines

    Securing Software with Intelligent Pipelines

    One of the biggest cybersecurity risks involves vulnerabilities in the application layer. After all, the best firewall is useless if the web application itself is vulnerable. Many companies have worked to mitigate these risks by investing in their AppSec programs. According to a recent whitepaper written by ESG (commissioned by Synopsys), 71% of companies surveyed now use AppSec tools for more than half of their software projects. Notably, over two-thirds of companies already use 11 or more automated application security testing (AST) tools, such as SAST, DAST, IAST, fuzz testing and container scanning solutions.

    This is due, at least in part, to the fact that tool manufacturers have now made their products “DevOps-ready” and support suitable integrations with CI/CD pipelines. This makes it tempting to simply let AppSec scanners run in the pipelines, but that can introduce other problems.

    Problems with AppSec in CI/CD Pipelines

    Too many results: Developers can be inundated with findings, yet only a small percentage are likely to pose such a high risk that they need to be fixed immediately. But the prioritization guidelines are often formulated in separate documents and are ambiguous.

    Development pipelines are slowed down: Build pipelines often run at frequent intervals; every second to every minute. Scans with AppSec tools may take several minutes or even hours.

    Manual AppSec activities are left out: Not all AppSec activities can be automated, such as architecture risk analyses, threat models and penetration tests. Nevertheless, these are an essential part of the AppSec strategy.

    Intelligent pipelines (i.e., intelligent, purpose-optimized automation and orchestration of the various AppSec tools and activities) are ideal for overcoming this challenge. Combined with the consolidation of scan results, a new category of solutions has emerged here, which Gartner dubbed application security orchestration and correlation, or ASOC for short, in 2019.

    How Pipelines Become Intelligent

    The “intelligence” lies in deciding which tools need to run at what time and what to do based on the results. So instead of scanning the entire codebase with AppSec tools at every commit, it dynamically decides which scanner needs to run and to what extent. This decision can take into account various parameters such as the scope of the actual code change, the risk profile of the application or the development stage of the software.

    The risk profile of the application should also be considered. Web applications that are accessible from the internet and process sensitive data pose a greater security risk than an internal tool for generating documentation. Such risk profiles usually emerge from prior architectural risk analyses and threat models.

    Furthermore, the scope of AppSec testing should be appropriate to the development stage of the application. Individual commits of a feature branch should be checked mainly by static code analysis for passwords and API tokens contained in the code and compliance with coding guidelines, such as SEI CERT, to support rapid development. Later on, during the merge request into the main branch, more extensive scans should be added, including deeper data flow analyses, which then detect cross-site scripting or SQL injection attacks. A longer runtime can be accepted here since such merge requests usually have to be approved according to the dual control principle.

    Code Security Policies

    The core of intelligent pipelines lies in individual guidelines or policies. These define when specific AppSec activities are executed. Additionally, these policies describe how to proceed with the combined results (e.g., whether the code may be integrated into the master branch or the web application may go live).

    The policies are described in a configuration file; this is policy–as-code. Just as with other as-code methods, this enables or improves uniqueness, reproducibility and automation. Simple policies can be created according to the “If this, then that” principle. For example, a software composition analysis (SCA) scan can be triggered when either the project file changes (package.json, go.mod, pom.xml, etc.) or new files or directories are added, but not when only existing source code files are changed.

    Conclusion

    Whether with or without orchestration tools, anyone who wants to make their software more secure must inevitably consider which AppSec activities make sense at what time. In other words: The right scan at the right time. Furthermore, it should be determined how to proceed with the results before ordering or even automating a scan. To do this, you need to understand what the greatest risks are and how to protect the software from those risks.

    Intelligent pipelines help to implement and, above all, automate an AppSec strategy. A corresponding strategy is a prerequisite. But even (or especially) without a clear strategy, it makes sense to look at the architecture of an intelligent pipeline, as this both encourages collaboration between development, AppSec and DevOps teams and raises the right questions that lead to a successful AppSec strategy.

  • Using Open Source to Secure Software Supply Chains

    Using Open Source to Secure Software Supply Chains

    Recently, there’s been a lot of attention paid to software supply chain security. In particular, here’s a quote from the May 2021 presidential executive order on improving the nation’s cybersecurity: “The Federal government must … advance toward zero trust architecture; accelerate movement to secure cloud services, including … platform as a service (PaaS).”

    There are two parts necessary to create a truly trusted software supply chain; securing the non-technical areas and securing the technical areas.

    Non-technical aspects of any secure software supply chain involve having individuals or teams focused on security and audit compliance. Internal company policies that act as a regulatory system and set standards for developers are a must, as are efforts to enforce compliance with security best practices. While this can bode well for large organizations, small software engineering teams and startups do not have the bandwidth, budget or culture to make this a reality.

    Envisioning Robust Security Best Practices

    Tools that are open source, governed strictly and enable automation of secure build and deployment are the components that form the technical aspects of the solution. Engineering teams must find a way to envision robust security best practices and find a way to apply them without unduly affecting the developer workflow. This is a founding principle of the DevSecOps efforts within the larger community of software development professionals.

    Ergo, advocating a technology stack that:

    • Is composed of open components
    • Provides automated builds
    • Reduces the dependency on developers
    • Allows security operators to extend control
    • and is actively supported by the community is an ideal choice upon which to build a platform for use by development teams.

    The focus of this article is to describe a robust stack that will sit above compute resources and power applications. The stack will consist of fully customizable open source components that put reliability and security at the forefront.

    Simplify Operations

    Application source code is the single source of truth when working with this stack. The use of Git, a popular version control system that is free and open source will allow developers to work with a source code management system from which all the downstream steps will be triggered.

    Kubernetes is an open source container orchestration tool developed under the auspices of the Cloud Native Computing Foundation (CNCF). It serves as an abstraction over the infrastructure and compute layers to power the system from underneath. Kubernetes has managed to gather a large community following—second only to the Linux OS itself. Using Kubernetes will bring homogeneity above the infrastructure layer and will simplify further operations.

    Cloud Foundry is an open-source PaaS tool. The use of Kubernetes introduces complexity that introduces a bit of overhead for developers who work with the platform. Cloud Foundry provides a countermeasure that simplifies the developer experience and greatly eases the pain points commonly associated with Kubernetes adoption. The Cloud Foundry platform does the job of deploying all the applications to the Kubernetes infrastructure. The cf push command triggers the export of a container image from the application source code.

    When building these containers to deploy to the runtime within Kubernetes, Cloud Foundry uses Paketo buildpacks internally. Paketo buildpacks are an implementation of the cloud-native buildpacks specification which aims to provide a unified means to generate OCI-compatible container images for all languages and frameworks that are commonly used to build applications. Paketo buildpacks are also open source and fully customizable according to the needs of software development teams.

    A Trusted Architecture

    Together, this platform, built on open tools, supported actively by the community and facilitating the exact needs of software developers helps promote a trusted architecture upon which to stage applications. Using these tools would enable an organization to build a software development ecosystem that satisfies all the requirements implied and enumerated in the various recommendations for improving software security.

  • Low-Code SaaS Solutions Need Security at Their Core

    Low-Code SaaS Solutions Need Security at Their Core

    Faster integrations. Accelerated software delivery. Elevated user experiences. These are only three of the benefits organizations gain by incorporating low-code platforms, apps and solutions into software development and business process management.

    Low-code platforms aren’t new, but demand for the technology soared in the last two years as companies were challenged to meet stakeholder demand for more digital transformation. With low-code tools, companies find they can expand digital transformation efforts through faster business application delivery. In addition, the time it takes to innovate is dramatically reduced with low-code tools.

    Low-code solutions are no passing trend. In their recent report on global cloud revenue, Gartner predicted that by 2025, the use of low-code and no-code will “nearly triple,” adding that “70% of new applications developed by organizations will use low-code or no-code technologies, up from less than 25% in 2020.”

    Low-code solutions give organizations the ability to produce working solutions and integrations with more speed and agility than more traditional on-premises development. Integration used to be a labor-intensive IT process requiring custom development on both sides of the integration. As more organizations adopt a “buy versus build” approach to software development, they are turning to self-service and other solutions with “out of the box” functionality to increase speed and efficiency. In addition, the vendor-developed components of low-code tools also offer a better user experience.

    Rising Demand for Low-Code, Platform-based Solutions

    As organizations expand their product and service offerings, the demand for low-code, platform-based solutions will increase. SaaS and PaaS solutions with a low-code focus can be effective for organizations looking for accelerated functionality. Often these tools include pre-built models and templates that businesses can quickly implement and easily duplicate for flexibility and versatility.

    The ability to create seamless integrations with other applications is a must. Best-of-breed low-code platforms enable intelligent integration between multiple applications using graphical user interfaces (GUI) as well as industry-standard interfaces such as JSON and APIs within vendor-supplied environments. Intuitive visual user interfaces and drag-and-drop features allow businesses to customize the solution to meet their needs and preferences.

    But along with ease of use and rapid functionality, organizations must look for low-code tools with security built-in.

    Security: A Priority for Low-Code Tools

    Security must be a top priority for organizations using low-code tools in any capacity, from using a low-code platform for application development or using a no-code SaaS solution for business process automation.

    Anytime an organization introduces outside applications or any third-party API integration to an environment, the organization is entirely dependent on the vendor’s security implementation. This is especially true when combining various solutions to create a unified product or service. If the vendor doesn’t take security seriously, other parts of a solution could be exposed to risk because of a weakness in another area.

    Problems can get in either intentionally or unintentionally, as demonstrated with the recent Apache Log4j vulnerability. The bug in this commonly used routine was found to have massive potential for cybersecurity attacks. As CNET cautioned, “The vulnerability in the widely used software could be used by cyberattackers to take over computer servers, potentially putting everything from consumer electronics to government and corporate systems at risk of a cyberattack.”

    Ways to Remedy Security Risks of Low-code Tools

    Organizations can’t make assumptions about the security of every tool, solution or platform they bring into their environment. They must complete their own due diligence for security in the software development pipeline or any time a 3rd party app or tool is introduced.

    One critical step to addressing security is incorporating DevSecOps and shifting security left in the software development pipeline. The Log4j vulnerability put the need for DevSecOps in the spotlight. Taking a shift left approach and implementing security earlier and more often in the DevOps process can help to catch more potential vulnerabilities. It’s critical to introduce DevSecOps early in the development cycle, or organizations risk missing a bug or vulnerability. In the development cycle, security isn’t an antivirus scenario; all code must be scanned for vulnerabilities.

    Organizations also need to employ due diligence when exploring options and solutions to bring into their environments. Look for solutions with security at their core. Before integrating any low-code solution, examine the vendor’s approach to security.

    Some security measures to look for when considering vendors or solutions include:

    • All communications should utilize at least TLS 1.2 (transport layer security) and comply with industry standards for certificates and encryption keys.
    • All hashing should be using current accepted standards with HMAC, they should be enforcing security rules on passwords such as only storing password hashes and requiring 2FA if they interact directly with customer accounts.

    Low-code platforms and tools have the ability to accelerate digital transformation efforts without having to rely on hand-coded, on-premises solutions. The potential for time savings and cost savings is significant, but it’s important for organizations to ensure they’re not compromising security when choosing solutions.

  • Best of 2021 – Torvalds’ Bug Warning is a Lesson for Linux Users 

    Best of 2021 – Torvalds’ Bug Warning is a Lesson for Linux Users 

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

    Linux does, occasionally, raise security concerns. While many users see it as the most secure, robust and versatile operating system available — that’s this writer’s opinion, as well — security precautions still have to be taken.

    A recent, widely publicized case illustrated this point; Linux creator himself, Linus Torvalds, warned against the use of the Linux 5.12 release. He described a “nasty bug,” and wrote that the situation is a “mess,” due to the use of swap files when adding Linux updates. This nasty bug, in fact, had the potential to destroy entire root directories.

    Some of the main takeaways following this “mess” include: tread very carefully when installing early Linux releases, especially those that involve swapping files instead of partitions, and especially, despite Linux’s well-known security advantages, avoid becoming complacent, because Linux security is not always foolproof.

    Hence, while the “state of Linux security today is quite good, and has evolved in a positive way with more visibility and security features built, like many operating systems, you must install, configure and manage it with security in mind; that is how cybercriminals take advantage, [via] the human touch,” said Joseph Carson, chief security scientist and advisory CISO at Thycotic, a provider of privileged access management (PAM) solutions.

    A Patch for Nastiness

    As Torvalds noted a few weeks ago, “most people don’t use a swap file, but a separate swap partition and the bug in question really only happens when you have a regular file system, and put a file on as a swap.”

    “The bad news is that the reason we support swap files in the first place is that they do end up having some flexibility advantages, and so some people do use them for that reason. If so, do not use [release candidate] RC1,” Torvalds wrote. “Thus, the renaming of the tag.”

    After issuing the warning, Torvalds released a patch that he says prevents the bug from destroying swap file systems. However, it may have already been too late for early adopters of release 5.12. Ubuntu, a leading Linux distro, can swap files by default.

    “It is nasty bug if you are still using swap files,” Carson said. “If you do still use swap files, then you could be impacted, resulting in potential data loss or a corrupted system.”

    DevOps teams – or anyone else running Linux and installing patches, whether on multi-servers or on individual workstations – still need, of course, to follow strict best practices. “Like any operating system, security depends entirely on how you use, configure or manage the operating system,” Carson said. “Each new Linux update tries to improve security; however, to get the value, you must enable and configure it correctly.”

    Linux Goodness

    The fact that Torvalds was so forthcoming about the bug, as well as the level of transparency that the Linux kernel offers, also demonstrates one of the many reasons Linux remains popular. Given that the Linux kernel, in one variety or another, is used “not only in about 50% of the internet servers of the world, but also in a substantial part of all our smartphones, it is good to see this level of transparency at ‘root level,” said Dirk Schrader, global vice president, security research at New Net Technologies (NNT), which providers cybersecurity and compliance software.

    “The security of Linux is based on its transparency; the ability to review the code of a distribution,” says Schrader. “Quite often forgotten is that transparency also involves talking about the mistakes, the errors, those nasty bugs.”

    Citing National Institute of Standards and Technology (NIST) vulnerability database statistics, Schrader described how, compared to the Windows family of desktop and server operating systems, for example, the Linux kernel shows better results for overall vulnerabilities. The number of vulnerabilities have also declined over the past four years, while Microsoft’s operating systems do not display the same trend, according to NIST’s national vulnerability database.

    Since Linux’s famous kernel is open source and transparent, it is possible to extrapolate that there are a greater number of potential vulnerability watchdogs compared to those monitoring vulnerabilities in closed systems. Some may argue that Microsoft has been, at times, less successful at detecting vulnerabilities and issuing much-needed patches.

    However, Linux users still must remain vigilant.

    “Still, for any of the Linux distributions, anyone using the early release candidates — RC1 in particular — should make sure that their own development or build process is undergoing change control, so that no mishaps will transfer the nasty bug into a production environment,”  said Schrader.