devopsy.kinsta.cloud

Category: DevOps and Open Technologies

Editorial Calendar for February 2016

  • Are Developers Responsible for Open Source Governance?

    Are Developers Responsible for Open Source Governance?

    There are lots of factors in the open source software world converging to make it a big year for “shift left” in software development. Heightened security concerns, an increasing need for software supply chain visibility and the growth and complexity of open source ecosystems will continue to push the responsibility for ensuring code is secure earlier in the engineering process as far left as the request and design phases.

    This means 2021 will be yet another year in which developers are challenged to take on more responsibility, and pushed further onto the front lines of open source governance. Developers will need access to the right training, resources and tools to do this job. But they also can’t be successful if they’re expected to do it alone. Shift left can’t mean shifting all responsibility to the developer as the sole protector of secure code and the only go-to open source expert. The reality is that the depth, breadth and complexity of open source governance in 2021 demands a cross-functional team and layered approach.

    Equipping Developers With Governance Knowledge

    Let’s start with how to better equip developers and other stakeholders in the governance process, including legal, security, IP compliance and product people. These teams need enough knowledge to be aware of the top compliance issues, and their corresponding remediation options, to be active contributors in this rapidly evolving space. Research from Forrester shows that of the top 40 computer science programs in the United States and the top five programs internationally, none include open source licensing and security coding practices in the curriculum.

    Instead, it has fallen to the industry itself to impart this expertise on the job. Leading companies are packaging open source training programs into something that resembles standard HR-led and managed training, including check-ins and quizzes to test and solidify knowledge, and regularly updating content and scheduling trainings to make sure people stay abreast of changes and challenges. In the spirit of open source, many industries work collaboratively to share best practices on governance in this regard, with industry experts speaking on the topic at other companies. Others are leveraging existing management training courses, such as the ones offered by the Linux Foundation.

    The growing importance of the Software Bill of Materials (SBoM) also points to the need for cross-functional collaboration. Software supply chain visibility will become even more crucial in 2021 so that companies can build and sell secure and safe products, as well as ensure compliance. More people across the organization will need to access and view the SBoM in ways relevant to their functional needs. As a result, its assembly is transforming from being assembly-line-esque (passed along and viewed in the context of siloed business functions) to becoming much more collaborative. The SBoM is becoming akin to a business intelligence tool, providing the ability for different functions and stakeholders to filter for relevant information.

    Depending on your function, you may be interested in a top-down view of the open source and third-party components across your portfolio of products in order to understand risks in the organization. For instance, as an engineering leader, you may want to understand if you are impacted by a new security vulnerability, where in your portfolio of products you may be exposed and the current status of remediation work for that vulnerability. If you are in legal, you may be interested in a significant licensing change for a component in use at your organization. This allows you to be prepared with changes to legal policies for automated reviews and obligation fulfillment guidance for engineering when the next build occurs and a more recent version of a dependency is pulled in. If you are in the export control function, and are required to provide your application’s encryption capabilities as part of the certification process, understanding which open source components are part of the application, and which provide cryptographic capabilities is essential. Finally, don’t overlook your customers, who today are requiring open source disclosures as part of commercial software contracts to protect themselves from insecure software.

    Collaboration has also been made simpler by the fact that new industry standards now enable an asset portfolio view of open source security. Open Chain obtained ISO certification in late 2020, ISO/IEC 5230:2020, providing a clear and effective process management standard for open source license compliance. It allows companies of all sizes and in all sectors to adopt the key requirements of a quality open source compliance program. Coupled with ISO/IEC 27001–the de facto standard for managing security in information security management systems (ISMS) – organizations can now take a more holistic view of all of their software assets in an effort to make the information they hold more secure.

    Open Source Program Office

    The best way to ensure developers aren’t left footing the bill for open source governance is to create a centralized team dedicated to it. Savvy organizations could form an Open Source Program Office (OSPO), which brings together key stakeholders in legal, engineering, product and security to develop, communicate and operationalize open source strategy for their entire organization. This team works to define a framework and process for consuming open source software as part of their development work (inbound use case) and/or contributing code to the community via open source projects (outbound use case). The mission and main charter of these teams is to help their organization create and manage an open source strategy in terms of the adoption, use, support, participation and development of open source software. However, they’ve also found their role has evolved to become the experts on open source internally and evangelists of the technology and its use.

    The bottom line is that the developer’s job is to develop software – and every piece put in place for stronger open source governance means less time spent focusing on the problems that could be in the open source code and more time on the promise of using it to rapidly innovate for the benefit of their customers.

  • WhiteSource Acquires Diffend to Secure Open Source Supply Chains

    WhiteSource Acquires Diffend to Secure Open Source Supply Chains

    WhiteSource this week announced it has acquired Diffend as part of an expended effort to discover malware that has been deliberately injected into open source software by a contributor acting in bad faith.

    Company CEO Rami Sass said cybercriminals are increasingly trying to compromise software supply chains that today depend heavily on open source projects. The Diffend platform surfaces anomalous contributor behavior that would be indicative of someone trying to compromise the integrity of a project, said Sass.

    Previously, WhiteSource provided a tool that would discover malware that had been inadvertently included in open source software. WhiteSource now plans to add the Diffend tools, now known as WhiteSource Diffend, for free to a portfolio of security tools that many organizations have already incorporated into DevSecOps workflows. Earlier this month, the company raised an additional $75 million in financing that, in part, was used to fund this acquisition.

    As cybercriminals begin to target software supply chains, many of them are taking aim at open source software that is likely to be adopted by a broad spectrum of organizations, noted Sass. The challenge is that bad actors have become adept at embedding malware in software components in ways that are difficult to detect, he said. However, spikes in activity from, for example, a new contributor to the project might warrant additional investigation, Saas added.

    These type of attacks, unfortunately, will require the maintainers of open source software to vet more closely who is allowed to contribute to the project, added SaaS. New contributors that might have once been greeted with open arms need to now be initially met with a modicum of paranoia, Saas said.

    That level of suspicion will be considerably higher if that contributor is located in a country that has a reputation for trying to compromise the security of both adversaries and companies that have intellectual property they might want to surreptitiously acquire.

    In the wake of some recent high-profile breaches involving software supply chain compromises, organizations are revisiting their application development processes. Cybersecurity teams are now asking developers to vet any external code that is incorporated within an application. Most applications regularly incorporate both open source and commercial components that developers assume have been vetted for malware when, in most cases, they have not. The Diffend platform, for example, aided in the detecting of 60 suspicious packages found in Rubygems, an open source platform that makes it easier to package software built using Ruby programming tools.

    It’s unclear how increased inspection of software components may impact application developer productivity. However, given how dependent organizations are on software today, the discovery of malware downstream that compromises the security of the application is potentially catastrophic.

    Sass said it’s doubtful these security concerns will lead to decreased reliance on open source software in general. There is no real alternative for efficiently driving software innovation, he said. The challenge now is finding a way to make sure all that innovation continues to occur as securely as possible.

  • Pulumi Moves to Automate Cloud Infrastructure Provisioning

    Pulumi Moves to Automate Cloud Infrastructure Provisioning

    Pulumi announced today it is expanding the scope of its automation ambitions to make it easier to securely provision cloud infrastructure-as-code.

    Joe Duffy, Pulumi CEO, said the Cloud Engineering Platform enables DevOps teams to use Pulumi Packages to create reusable components for automating IT infrastructure provisioning in a way that can be embedded within workflows and applications using an application programming interface (API) that Pulumi has exposed. IT teams can define a Pulumi Package in the programing language of their choice, Duffy noted.

    The Cloud Engineering Platform is now generally available on the Microsoft Azure cloud, while a preview edition of the offering is available on Google Cloud Platform. Support for Amazon Web Services (AWS) is planned for later this year.

    The platform itself is based on version 3.0 of Pulumi, an open source tool that developers have previously employed to manage infrastructure-as-code. Pulumi is also making generally available a tool for integrating its tools with more than a dozen continuous integration/continuously delivery (CI/ CD) platforms.

    That capability, coupled with existing support for integrated testing capabilities and the tools for managing compliance-as-code based on identities, provides IT teams with a more comprehensive approach to managing infrastructure-as-code, said Duffy.

    Most cloud resources today are directly provisioned by developers using open source tools such as Terraform. The issue that organizations have encountered is that developers are prone to making configuration mistakes that cybercriminals then exploit. Pulumi is making a case for an alternative approach to provisioning infrastructure-as-code that makes it easier to validate configurations using testing tools, while at the same time limiting who can access infrastructure resources by including support for the secure access markup language (SAML) and single sign-on (SSO) capabilities.

    It’s not clear at what rate enterprise IT organizations will be shifting toward platforms that enable infrastructure to be managed as code in a more robust fashion. Developers that don’t always have the greatest appreciation for cloud security issues routinely employ tools such as Terraform to provision infrastructure-as-code with little to no supervision. Cloud resource misconfigurations often result in ports left wide open, and cybercriminals now make use of tools to scan for those types of misconfigurations.

    Pulumi Packages provides a means for IT teams to exercise more control over the provisioning process, using vetted reusable components in a way that doesn’t compromise the rate at which developers can spin up cloud resources, noted Duffy.

    As organizations focus more on software supply chains in the wake of some recent high-profile breaches, it’s only a matter of time before more questions arise about how cloud infrastructure is being provisioned. Much of the concerns organizations already have about cloud security doesn’t stem from the platforms themselves. Rather, it’s the processes employed to provision infrastructure under a shared cloud security responsibility model that results in so many vulnerabilities. Many developers assume the cloud service provider is securing configurations, only to discover later that it was their responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned.

    Hopefully, there will come a day when DevSecOps best practices leverage automation to resolve this issue once and for all. The challenge is finding the best way to achieve that goal in a way the average developer will accept and embrace.

  • Is Open Source More Secure Than Closed Source?

    Is Open Source More Secure Than Closed Source?

    There’s no getting around the fact that security is one of the most essential factors in day-to-day operations for most software developers. From proprietary code to sensitive customer data and everything in between, there are hundreds – if not thousands – of crisis scenarios that can result from gaps in security.

    Data security is an issue that every company faces, no matter how large or small. Developers look for security solutions that follow today’s data and application security best practices in order to reduce risk and provide the most secure experience possible to the end user.

    A common debate among both users and developers is whether open source software is more or less secure than closed source alternatives. While there are a variety of different schools of thought as to what makes for a truly secure environment, there is good reason to believe that open source software is the superior option for those looking to prioritize security.

    While open source code may not be inherently more secure than its closed source brethren, here are a few reasons why it almost certainly can be — so long as you take the right approach.

    Open Source Offers True Transparency

    Both well-established tech giants and up-and-coming startups work with some of the brightest minds in the development community to bring valuable proprietary software products and services to market. At the end of the day, however, users have no choice but to trust what a vendor says about how a particular piece of software actually “works.” Since you can’t see the code itself, there’s no way to really verify whether or not what you’re being told – about features, functionality and security – is accurate.

    This can be problematic for a host of reasons—not least of which being the threat of potential security flaws. A company might boast about its commitment to user security and privacy through savvy public relations and product marketing efforts. But, by no means does this provide the user with anything more than lip service if the code doesn’t measure up; even if it’s rock-solid, the question of “How truly secure is this?” can never be answered with confidence.

    Open source software offers greater transparency to the teams that use it; visibility into both the code itself and how it is maintained. Giving organizations access to the source code allows them the opportunity to evaluate the security of the code for themselves. Additionally, users have more visibility into how and what changes are made to the code base, including the pre-release review process, how often dependencies are updated and how developers and organizations respond to security vulnerabilities.  As a result, open source software users have a more complete picture of the overall security of the software they’re using.

    Open Source Encourages Community Input

    Another major benefit is found in the communities which drive the growth and development of open source software. The vast majority of open source software is backed by communities of forward-thinking developers, many of whom use the same software they build and maintain as a primary means of communicating with team members. Open source developers and the communities around the software value users’ input to a significant degree, and many user suggestions end up getting incorporated into new versions. The community involvement and investment ultimately leads to many more responsible vulnerability disclosures than would likely occur if the software was closed source.

    When vulnerability reports do occur, they tend to be more detailed because the code is open source; often, they even come with code suggestions for how to remedy a given issue. This is incredibly helpful and can dramatically speed up patching the vulnerability, as it allows developers to move faster without spinning wheels and getting stuck in the diagnostic process.

    Faster Security Updates

    Within the framework of closed source software, users are at the mercy of the companies behind those products or services when it comes to receiving software updates―open source tends to be a different story. Fully open source projects even allow users and developers to take things into their own hands and contribute feedback and fixes, should they choose to do so.

    More often than not, updates and fixes for high-profile closed source applications involve a great deal of complex planning. If it’s not in the budget, for example, users may not see a new update for weeks, months, or even longer—security flaws or not.

    In most circumstances, open source tends to move faster than closed source when it comes to iterating and releasing new versions. This is true for a handful of reasons, including the fact that open source software tends to have more eyes on the source code at any given time, as well as a community-driven interest in bettering the product whenever possible. If a significant security flaw is uncovered, users may even choose to fix the code themselves, resulting in a level of control that can never be achieved in a closed source environment.

    Open Source Offers Flexibility, Collaboration and Enhanced Security

    An open source methodology, in and of itself, is no guarantee of security, but it does offer teams greater insight and control over the software they rely on. And as open core and source-available software are more broadly adopted, they offer a wealth of opportunities to build incredibly secure environments without sacrificing usability for end users or support from official maintainers.

  • RapidAPI Adds Library to Invoke Kafka via API

    RapidAPI Adds Library to Invoke Kafka via API

    RapidAPI announced it has added support for the open source Kafka messaging software as another type of application programming interface (API) that DevOps teams can centrally access.

    An open source library provided by RapidAPI, available in beta, makes it possible to discover Kafka clusters and topics, view schemas and test and consume records from a browser via either the RapidAPI Marketplace or the RapidAPI Enterprise Hub. The library is based on Apache Avro and Confluent wire formats found in the open source confluent-schema-registry library. RapidAPI extended that library to add support for JSON and a protocol buffer, which is now being shared with the open source Kafka community.

    RapidAPI CEO Iddo Gino said DevOps teams can now discover all available Kafka clusters and instances in the same location where they find, test and connect to microservices based on REST, SOAP and GraphQL APIs. That effort is designed to complement initiatives, such as the AsyncAPI specification, that is now being advanced under the auspices of the Linux Foundation, Gino noted.

    RapidAPI is adding this capability because usage of Kafka to enable asynchronous communication across event-driven applications has significantly increased, Gino said. As the number of digital business transformation initiatives increased in the wake of the COVID-19 pandemic, Gino said reliance on asynchronous messaging platforms such as Kafka became a requirement. In many cases, synchronous communications across highly distributed applications simply isn’t feasible, Gino added.

    That doesn’t mean asynchronous requirements will replace the need for traditional synchronous APIs. Rather, developers will find themselves incorporating a greater mix of both as enterprise IT environments become more distributed, noted Gino. Applications are increasingly become one large puzzle that developers need to construct using various classes of APIs, added Gino.

    The library created by RapidAPI is expected to be generally available in the third quarter. In the meantime, adoption of Kafka continues to accelerate. The open source community that oversees development of Kafka, under the auspices of the Apache Software Foundation, claims more than 80% of all Fortune 100 companies are using the platform for everything from constructing data pipelines to running streaming analytics applications. In some cases, data is being queried directly while in transit versus waiting for it to be stored on-premises or in the cloud.

    Regardless of how Kafka is employed, developers are rediscovering event-driven architectures, that can trace their lineage to the 1980s, for building applications. The difference now is there an open source framework for handling the asynchronous communications required to build and deploy those applications at scale.

    It’s not quite clear how the rise of event-driven applications will impact DevOps workflows, as event-driven applications become more commonly built and deployed. However, as the APIs become more widely employed within the context of these applications, it should become simpler to incorporate them.

    The challenge is event-driven architectures typically requires developers to think differently about how their applications are structured, so it might be a while before Kafka – and other similar platforms – are pervasively employed across the enterprise.

  • Gitpod Revamps Dev Automation Tool

    Gitpod Revamps Dev Automation Tool

    Gitpod announced today it refreshed the dashboard for its namesake open source tool for automating the deployment of development environments, in addition to making Microsoft VS Code its default tool for editing code.

    In addition, Gitpod has included support for sudo privileges and Docker images using an advanced user namespace to map and limit access to workloads using a built-in Supervisor capability.

    Fresh off raising an additional $13 million in funding, Gitpod CEO Sven Efftinge said now that it’s clear developers will be working from anywhere for the foreseeable future, the need for a tool to automate setting up a developer environment on a local machine outside of an office has become more apparent.

    Gitpod claims there are now more than 350,000 developers using its tool that creates a Kubernetes pod on each developer machine to deploy a complete application development environment, including the integrated development environment (IDE), plugins, compilers, build tools, code generators, databases and application servers. Gitpod makes use of the version control systems provided within, for example, a continuous integration/continuous delivery (CI/CD) platform as the single source of truth for configuring an application development environment.

    The overall goal is to eliminate the time developers waste setting up application development environments so they can write code on their own machines. That approach also makes it simpler for developers to collaborate around the same application development environment regardless of where they happen to be physically located.

    Efftinge said Gitpod provides DevOps teams with a tool to automate setting up development environments across any Git repository that is the equivalent of the Codespaces tool that GitHub recently made available. Rather than having that capability for only one repository, Efftinge noted that most developers work on projects that span multiple types of repositories.

    Automating that process also makes it simpler to align development environments with production environments. One of the reasons why code doesn’t work in a production environment when it is first deployed is because the local development environment has been manually configured in a way that doesn’t accurately reflect the production environment. That issue can become even more problematic when developers are working on multiple projects involving, for example, separate microservices constructed using different repositories.

    In the wake of the COVID-19 pandemic and the acceleration of multiple digital business transformation initiatives there’s naturally a lot more focus on automation and developer productivity. Most developers will be working outside the office for the foreseeable future. Of course, most developers have been writing code outside the office for years. The challenge now is enabling teams of developers to develop applications as efficiently as possible, no matter where they are in the world. In fact, now that development teams have become more distributed, organizations are becoming more comfortable hiring developers wherever they find them.

    Eliminating inefficient manual tasks, such as maintaining development environments, is, of course, going to be a prerequisite for making it possible for those developers to, over time, navigate multiple application development projects without ever having met their colleagues in person.

  • Apollo GraphQL Makes Federated Server More Accessible

    Apollo GraphQL Makes Federated Server More Accessible

    In advance of its online GraphQL Summit this week, Apollo GraphQL announced today it has updated its Apollo Federation offering that enables a GraphQL Server to span multiple platforms, making it more accessible to a wider range of developers using different tools.

    Apollo Federation is now integrated with both Apollo Studio, a web-based tool for navigating GraphQL application programming interfaces (APIs), and Apollo Workbench, a plugin for Microsoft Visual Studio.

    At the same time, Apollo GraphQL is making available a command line interface (CLI), dubbed Rover, that makes it simpler to integrate Apollo Federation within a DevOps workflow.

    Matt DeBergalis, CTO, Apollo GraphQL, said GraphQL is continuing to gain traction as an alternative to more rigid REST APIs as more organizations begin to appreciate how dependent they have become on software. REST APIs may be simpler for developers to create, but APIs based on GraphQL are easier to update and manage, DeBergalis noted.

    Apollo GraphQL

    The challenge organizations encounter is that a GraphQL Server can become too large to easily navigate. Apollo Federation provides a mechanism that enables of subset of those APIs to be managed on multiple platforms that make up a federated instance of a GraphQL server, DeBergalis explained.

    DeBergalis also noted that IT vendors that have embraced GraphQL are also starting to add support for Apollo Federation. DataStax, a provider of a curated instance of the open source Cassandra database, has added Apollo Federation to the open source data gateway Stargate it provides to access data stored in a Cassandra database.

    At its core, QraphQL provides an open source data query and manipulation language for APIs along with a runtime for fulfilling queries. Originally developed by Facebook, the GraphQL Foundation is now an arm of the Linux Foundation. As more organizations embrace APIs to construct applications based on microservices, GraphQL adoption has steadily increased. It’s not likely GraphQL will completely replace REST APIs any time soon, however, given how pervasively deployed REST APIs already are.

    However, DeBergalis said that organizations that require a more agile approach to building and deploying software are voting with their feet for GraphQL APIs that are easier to update. As the rate of change in software environments continues to increase, the need for a more flexible approach to deploying and updating APIs becomes that much more apparent, added DeBergalis.

    GraphQL is also more efficient than REST APIs in terms how much data is shipped back and forth between a client and a server. At a time when the amount of data that is being consumed is steadily increasing, the need to give clients more control over how data is returned from a server has become more pressing. Apollo GraphQL claims more than two billion queries per day are now being launched against instances of its GraphQL Server.

    Regardless of what types of APIs are employed there are more of them with each passing day. As the number of digital business transformation initiatives increased in the wake of the COVID-19 pandemic, so too did the number of internal and external facing APIs. Developers may have their own individual preference for the type of API they want to use, but as developers are increasingly being tasked with both building and managing APIs after they are deployed, the appeal of GraphQL becomes harder to ignore.

  • AlmaLinux Foundation Delivers on CentOS Promise

    AlmaLinux Foundation Delivers on CentOS Promise

    A nonprofit organization launched this week to oversee future development of AlmaLinux, a distribution of Linux based on code originally contributed to the open source CentOS project.

    At the same time, CloudLinux, which created AlmaLinux in response to a decision by Red Hat to pull financial support for CentOS, announced that a stable version of the operating system is now available. CentOS itself was based on the Red Hat Enterprise Linux (RHEL) distribution that is made available via a subscription.

    Jack Aboutboul, community manager of AlmaLinux, said AlmaLinux is the result of the $1 million that CloudLinux committed toward creating a distribution of Linux based on a CentOS project used by hosting providers, such as CloudLinux, to run RHEL-compatible applications at a lower cost. AlmaLinux OS is a binary compatible fork of RHEL 8, which the foundation pledged to update to maintain that compatibility.

    AlmaLinux is one of two distributions based on CentOS that have been created. The other, RockyLinux was created by Gregory Kurtzer, one of the original creators of a CentOS project. Red Hat, in the meantime, has moved to make RHEL subscriptions available for free to individual developers.

    Aboutboul said AlmaLinux is more mature than RockyLinux, because it is based on a Linux distribution that has been battle-tested by IT service providers. AlmaLinux also added a SecureBoot capability as well as support for VMware and the Amazon Web Services (AWS) public cloud, noted Aboutboul.

    The AlmaLinux Foundation also decided to publicly share errata about the ongoing development of the operating system, to make it easier for IT teams to troubleshoot issues that might arise in a production environment.

    It’s not clear yet how much support either AlmaLinux or RockyLinux have. However, at this juncture, forks are becoming fairly common across the open source community. Those disruptions, however, don’t seem to be dampening enthusiasm for open source software. A global survey of 1,250 IT leaders conducted by Red Hat finds nearly 80% of respondents expect to increase their use of emerging open source software technologies over the next two years, with the top three use cases being infrastructure modernization (64%), application development (54%) and digital transformation (53%).

    As Winston Churchill famously said, democracies are messy, and the open source community is no exception. Passions run high. At the same time, the various business models that spring up around open source projects often conflict; because of animosity, greed or differences of opinion, it is not uncommon for multiple forks of an open source project to emerge and evolve over time.

    Despite that issue, IT organizations remain committed to open source for two primary reasons. First, no one needs permission to download open source software to a laptop. That enables developers to more easily experiment with new technologies. Second, cost. Many IT organizations prefer to use free open source software, rather than paying to license commercial software. They may one day pay for support, but the number of open source software users still dwarfs the number willing to pay for support; especially since knowledge and expertise is freely and equally shared across a growing open source community.

    Given those benefits, any friction in the open source community itself is largely seen as an acceptable risk and just the potential cost of doing business.

  • 42Crunch API Security Platform Now Available On-Premises

    42Crunch API Security Platform Now Available On-Premises

    42Crunch has announced that the scanning tools it provides to enable DevOps teams to secure application programming interfaces (APIs) can now be deployed in on-premises IT deployments.

    Previously only available as a cloud service, the 42Crunch API Security Platform has also been updated to provide expanded support for the OpenAPI specification for REST interfaces defined by the OASIS standards body.

    Finally, the 42Crunch API Security platform now allows IT teams to share collections of APIs among specific teams and users with different levels of access in addition to providing integration with third-party identity management platforms.

    Dmitry Sotnikov, chief product officer for 42Crunch, said the on-premises edition of the API scanning platform will make it possible for IT organizations, including those that require all the platforms they run to be deployed in an IT environment, to exercise more control over and extend their DevSecOps workflows to include scans of APIs.

    Cybercriminals are increasingly targeting insecure APIs because they potentially provide access to a trove of data, Sotnikov noted. Those same APIs also enable cybercriminals to compromise an entire software supply chain, Sotnikov added.

    At a time when more organizations are deploying APIs, thanks to the rise of microservices, it’s apparent there is a greater need for a tool that dynamically scans APIs for vulnerabilities before they are deployed, said Sotnikov.

    In general, Sotnikov said IT organizations are becoming more sophisticated in their approach to securing software. Ford Motor Co., for example, is using the 42Crunch API Security Platform to secure both internal and external APIs, Sotnikov said. 42Crunch claims its revenues increased 900% in 2020, with more than 150,000 users of the platform.

    As organizations of all sizes become more dependent on software, cybersecurity teams are now reviewing how that software is constructed. Of course, responsibility of security is still shifting left as part of the overall transition to DevSecOps best processes, but Sotnikov said cybersecurity teams still want to verify for themselves that whatever software is deployed is secure. IT organizations are moving away from a “whack-a-mole” approach to security as they embrace DevSecOps, Sotnikov added.

    Unfortunately, APIs don’t always receive the level of attention they deserve. Many developers still tend to view them as an afterthought, and once deployed, it’s not uncommon for APIs to languish for years without being reviewed or updated. Making sure APIs are secure requires dynamic scanning processes to be baked into DevOps workflows if organizations want to ensure the integrity of their software, said Sotnikov.

    APIs are, of course, everywhere now. The days when a handful of APIs were exposed to share data with a limited number of customers and partners are long over. There are almost no applications built and deployed today that doesn’t expose myriad APIs. Cybersecurity teams obviously can’t keep pace with the rate of change being made to those APIs, as new ones are added and others updated or replaced. The onus for securing all those APIs is, now more than ever, clearly on the DevOps team.

  • Red Hat Survey Reveals More Confidence in Open Source

    Red Hat Survey Reveals More Confidence in Open Source

    A recent Red Hat survey revealed how DevOps teams increasingly depend on open source to support their shift to cloud-native environments and digital transformations, and to maintain security in these highly distributed environments.

    Based on a survey of 1,250 IT professionals, Red Hat maintains that the survey respondents — from organizations that were Red Hat customers — were unaware that Red Hat sponsored the study to help avoid “biased or influenced responses,” Red Hat said in a statement. 

    During the past two years, the number of organizations that deemed open source necessary for their digital transformations increased 11% to 53%, representing the majority of the respondents’ organizations. 

    The vast majority (87%) of the respondents considered open source to be “more secure” than or “as secure” as proprietary software, while 84% indicated that enterprise open source “is a key part of my organization’s security strategy.”

    While the survey reflects open source’s importance for security for IT professionals in DevOps, its support of the overall business mission is key, as well, says Momodou Jaiteh, application security consultant at nVisium, an application security provider.

     “Information security is about reducing and mitigating risk to enterprises, from technology, people and process perspectives. It helps enable the business to operate securely in the best interest of its shareholders and customers,” Jaiteh said. “Thus, security typically plays a supporting, [but] nonetheless critical role in the success of the business, especially in a digitally connected world.” 

    Open source software often helps businesses reduce overhead cost in delivering services to their customers through reduced time to market, Jaiteh said. One major additional advantage is “visibility and input from a lot of different people,” Jaiteh added. 

    “Greater visibility often translates to more observing eyes on all aspects of the open source software, which often translates to better security. This is even better for mission-critical software that deals with sensitive information, such as cryptographic algorithms, etc.,” Jaiteh said. “It is not a surprise to see open source used more in infrastructure modernization, because as we move to DevSecOps models of software delivery, infrastructure often is the bottleneck. Therefore, solving for infrastructure helps developers focus on aspects that are unique to their business.”

    While survey respondents ranked improving collaboration between IT and business stakeholders to achieve a digital transformation as their highest priority, implementing cloud technologies or infrastructure ranked second. Infrastructure modernization is thus seen as a prerequisite for a full digital transformation, said Dirk Schrader, global vice president, security research at New Net Technologies (NNT), a cybersecurity and compliance software provider.

     “Open source plays a vital, pivotal role in almost all digital trends driving any industry sector today,” Schrader said. “Cloud computing or containerization is rooted in open source technology, many development libraries are open source, and the market for open source solutions has been a model for servitization; the changes in one’s business model away from selling a product to selling a service, or an integration of service, and product that focus on additional value-add for the customer.”

     For security, the main advantages consist of being able to review, inspect and audit “each and every piece of code,” Schrader said. 

    “The ability of open source to be a base for services makes it the natural companion for any digital initiative,” Schrader said.