Category: DevOps and Open Technologies

Editorial Calendar for February 2016

  • Microsoft Expands Azure DevOps Portfolio

    Microsoft Expands Azure DevOps Portfolio

    Microsoft has made available a bevy of updates to its DevOps portfolio that, collectively, are intended to increase its share of a wave of applications that will be rolled out across the extended enterprise.

    Additions to the Microsoft DevOps portfolio were announced at the Microsoft Ignite 2021 conference and include DevOps Workflow Generator, a free tool designed to help DevOps teams visualize their toolchain, and updates to Azure Automanage, a framework for automating the management of virtual machines on Windows Server and, in preview, on Linux.

    At the same time, Microsoft has added support for open source OpenTelemetry agent software to Azure Monitor and made available a preview of Azure Chaos Studio, a service for testing application resiliency.

    Microsoft is also making available a preview of Windows Server 2022 that adds secure-code capabilities for workloads deployed on the platform. Microsoft also previewed updates to backed databases such as SQL Server 2022, Cosmos and its implementation of the Redis database created by Redis Labs.

    Finally, Microsoft has also made available a preview of integration between GitHub Actions for automating software development tasks and Azure Active Directory (Azure AD) using Open ID Connect, an authentication protocol advanced by the OpenID Consortium.

    Microsoft CEO Satya Nadella told conference attendees the next 10 years will witness more digitization than the previous four decades as IT shifts from an era defined by mobile and cloud computing to one defined by ubiquitous computing and ambient intelligence.

    Applications built in everything from procedural code to the Microsoft Power Fx, a low-code tool that Microsoft created using the programming language it originally built for users of the Microsoft Excel spreadsheet. Microsoft envisions those applications will primarily be built on its cloud and distributed everywhere. On the backend, a range of database and artificial intelligence (AI) services will be invoked primarily via application programming interfaces (APIs).

    Of course, every major cloud service provider has similar ambitions. Most organizations today are not standardizing on a single cloud. Rather, they are determining which class of workloads run best on which cloud computing platform regardless of whether that approach increases the total cost of IT. Each additional platform adopted typically requires IT teams to master separate tools. However, Microsoft is now also making a case for a cloud-native framework that can be deployed anywhere to build, deploy and manage applications.

    In the meantime, the number of workloads deployed on cloud services continues to grow. The market research firm Canalys reported worldwide spending on cloud infrastructure services reached $49.4 billion in the third quarter of 2021, a 35% increase. Microsoft currently trails Amazon Web Services (AWS) in overall market share but continues to steadily make gains. Microsoft and AWS collectively account for roughly half of all cloud infrastructure service consumption.

    DevOps best practices will need to evolve to meet the challenges of multi-cloud computing. In addition to cloud platforms and on-premises IT environments, applications are now starting to be deployed at the edge in greater numbers. DevOps teams need to be able to continuously deploy applications and their associated updates across a wide range of platforms. The challenge, of course, is that all those platforms have unique attributes that make truly automating the entire process on an end-to-end basis an elusive goal.

  • NextArch Foundation Launched to Focus on Microservices

    NextArch Foundation Launched to Focus on Microservices

    The Linux Foundation this week launched the NextArch Foundation to define frameworks and specifications that promote interoperability between microservices that span multiple cloud computing environments.

    More than 40 organizations, including Tencent, Arm, Kong and Ampere, have committed to contributing to 10 technology projects in 2022 in addition to frameworks for three vertical industries.

    Mark Shan, chairman of Tencent Open Source Alliance, said within the next five years the NextArch Foundation expects to have defined a set of standards and best practices that will have been widely adopted.

    The NextArch Foundation’s mission is to provide a home for a set of emerging technologies that would otherwise not get the attention they deserve within the confines of an existing consortium, said Shan.

    NextArch Foundation’s areas of focus will include how continuous integration/continuous delivery (CI/CD) platforms are employed to build microservices and reducing latency between microservices residing in highly distributed computing environments, added Shan.

    It’s not clear where the efforts of NextArch will begin and end as compared to the Cloud Native Computing Foundation (CNCF), another arm of the Linux Foundation that focuses on platforms such as Kubernetes that are widely used to build and deploy microservices-based applications based on containers.

    In general, however, it’s already apparent that microservices are at the core of most digital business transformation initiatives that span everything from artificial intelligence (AI) projects to edge computing environments. The global digital transformation market size was valued at $336.14 billion in 2020 and is expected to grow at a compound annual growth rate (CAGR) of 23.6% from 2021 to 2028, according to market research firm Grand View Research.

    As organizations embrace microservices to build and deploy software, the need to establish a set of DevOps best practices to manage them given the level of dependency that exists between multiple microservices within any application.

    Challenges associated with managing microservices are not likely to deter organizations from adopting them, but they do slow down the transition. Most new applications are intended to run on mobile devices that access cloud services, and typically run more efficiently when constructed as a set of microservices that scale up and down based on usage. The levels of agility and resilience that microservices have are crucial to any digital business transformation initiative, so the general expectation is that the percentage of microservices-based applications that will be running in production environments will increase sharply.

    The challenge, of course, is that, over time, microservices-based applications are more challenging for developers to build and maintain than a traditional monolithic application, though they are easier to update. It’s not likely microservices-based applications will replace existing monolithic applications overnight, but many existing monolithic applications are being converted into a set of microservices that makes it easier for developers to reuse the core functionality of that application.

    Of course, it’s still early days as far as microservices in the enterprise are concerned, but as developers shift toward a new way to build software, the need for a wider range of de facto standards should become more apparent.

  • DevSecOps Tech Radar Highlights Diverse Tooling Adoption

    DevSecOps Tech Radar Highlights Diverse Tooling Adoption

    The DevSecOps Technology Radar showcases the opinions cloud-native groups have about DevSecOps tools. To review, The Technology Radar is a periodic report from the Cloud Native Computing Foundation (CNCF), a burgeoning host for new open source projects that are becoming pivotal underpinnings to cloud-native architecture at large.

    Just like previous radars, the DevSecOps Technology Radar was assembled using feedback from the CNCF end-user community, which is a group of over 155 organizations that use cloud-native technologies to build and distribute their services, spanning startups and enterprises. The Radar report organizes popular tools into adopt, trial and/or assess status, based on a technology’s active use and its maturity.

    ‘Adopt’ means these tools are stable and come highly recommended for use in production systems.

    ‘Trial’ means users have had some success with these tools, and it is recommended that others consider them.

    ‘Assess’ means these are promising tools that are good for solving specific needs.

    So, why was DevSecOps selected as this Radar’s theme? According to the Radar team, DevSecOps was chosen because it is highly relevant to current development focuses. “We realized that more than half of the tools we were using in CI/CD were actually security-oriented,” said Sergiu Petean, head of DevOps at Allianz Direct. This goes beyond DevOps—”this is definitely an uppercase ‘Sec’,” he said.

    “More than half of our time is spent discussing designs around security,” said Keith Nielsen, director, cloud architecture at Discover Financial Services. Financial services especially must find innovative methods to balance speed-to-market with security. Nielsen also cited the rapid rate of change in this space, which requires companies to continually reevaluate their security posture.

    DevSecOps Radar Results

    So, where did the CNCF end-user community place popular DevSecOps tools? The Radar ended up rating 16 tools across the three different levels:

    • Adopt: Istio, Sonarqube, Artifactory, Hashicorp Vault, Calico/Tigera, Terraform, ArgoCD and OPA.
    • Trial: XRay.
    • Assess: Cilium, Harness, SonaType Nexus, Hashicorp Sentinel, GitHub Actions, Linkerd and Trivy.

    The above results were based on 252 votes from end users across 35 tools, with most respondents coming from large companies across multiple sectors.

    Out of these tools, Terraform collected the highest number of ‘Adopt’ votes. This technology aids the move toward infrastructure-as-code (IaC) with declarative configuration files, which is important for DevSecOps automation. Tied for second place were Hashicorp Vault and Artifactory, indicating that secrets management, access control and continuous updates for security are pressing requirements.

    Other open source tools on the Radar are providing impressive ways to unify security controls. For example, OPA is a universal layer for applying policies that could help unite fragmented authorization across applications. Or, service mesh options like Linkerd and Istio place a sidecar proxy around applications to centrally manage access control, observability and networking across a large microservices ecosystem. Such projects are programmable to fit into the DevSecOps pipeline.

    Analysis

    In general, the radar team was somewhat surprised to see such a high number of security tools in use today. Some tools compete in the same arena, making hunting for the right tool challenging. “The sheer number of products is a bit staggering … what we’re seeing is a highly fractured strategy from different companies,” explained Nielsen, who said he expected more consolidation on capabilities.

    After evaluating the DevSecOps tooling landscape, The Radar team organized their core findings into three main takeaways:

    Usability is compromised at the expense of security. Security features are necessary, but they often come at the cost of usability. The DevSecOps Radar team found that the developer experience for most tools is poor. Many disparate tools must be stitched together to have a truly automated pipeline which is cumbersome to implement. “The tools are getting better, but still there’s not a cohesive, prescriptive way to develop for the cloud,” said Nielsen.

    The pace of change in the security space is rapid. Major cloud providers continue to rapidly release new services, which has led to an explosion in new tools. Simultaneously, the speed of innovation is accelerating within companies, opening up unique security needs. Combined, this means the security landscape is constantly shifting. “Security tools are trying to keep up with the services and how you host them and run them,” Nielsen said. “We definitely weren’t expecting to see so many newcomers in the security space,” Petean agreed. Though DevSecOps is spoiled for choice these days, “it’s always better to have options,” he added.

    Microsegmentation is important but presents a significant challenge. Many great tools enable companies to improve how they segment traffic, such as service mesh tools like Linkerd and Istio. However, implementing cloud-native microsegmentation is bumping against legacy implementations for established companies. Between API gateways, service mesh, edge firewalls and Kubernetes federated firewall functions, DevSecOps has much complexity to deal with, Nielsen said.

    The DevSecOps Technology Radar: In Review

    In recent years, cloud-native technology has placed increasing emphasis on solving the security puzzle. Companies continue to reevaluate their security approach in light of cloud-native strategies, novel vulnerabilities and new compliance requirements. DevSecOps is proving to be a useful, if not necessary, practice to maintain both security and rapid software delivery.

    With new security tools and unique approaches coming out so frequently, it’s easy to have “analysis paralysis.” However, DevSecOps must start somewhere. And, for those who trust the opinions of the CNCF Technology Radar, you now have some helpful insights on where to begin.

  • GraphQL’s Greatest Strength is Also its Greatest Weakness

    GraphQL’s Greatest Strength is Also its Greatest Weakness

    Michael Scott: Why don’t I tell you what my greatest weaknesses are? I work too hard, I care too much and sometimes I can be too invested in my job.
    David Wallace: Okay. And your strengths?
    Michael Scott: Well, my weaknesses are actually strengths.
    David Wallace: Oh. Yes. Very good.

    GraphQL is a new query language that offers a simple way to interact with structured data. The best thing about GraphQL’s design is its convenient data fetching process which enables the requesting party to collect limitless data and perform multiple actions, all with a single API call. This interaction method makes it super useful and very easy to use. However, from a security perspective, its greatest strength could also be its greatest weakness.

    I recently met with Elad Koren, chief product officer, Salt Security, to understand the nuances of GraphQL security. According to Koren, GraphQL affords better usability than REST APIs, yet its bundled request model may compromise systems that don’t employ proper object-level authorization checks. Also, since developers interact with GraphQL services differently than typical web APIs, hackers could avoid detection by typical firewalls, requiring a new approach to security.

    These concerns aren’t dealbreakers for adoption; rather they are a reality check for those using GraphQL in production. Below, we’ll explore some potential weaknesses and look at some general mitigations that providers can take to improve the confidentiality of their GraphQL endpoints.

    What is GraphQL?

    GraphQL was initially developed by Facebook and open sourced in 2015. It’s a query language that makes data retrieval and manipulation with external sources very easy. Instead of programming and linking together complex calls with traditional HTTP API requests, GraphQL enables a client to bundle queries into a single request. This design pattern reduces the under- and over-fetching pattern that REST APIs typically suffer from.

    “You get exactly what you need, not more or less,” described Koren. This makes GraphQL a popular choice for modern database mechanics over REST, as it’s similar to SQL querying.

    Adoption of GraphQL is steadily growing; a 2020 RapidAPI survey found GraphQL usage had quadrupled. GraphQL is now used by 22.5% of API developers. But when it comes to overall API design patterns, REST is still the dominant architectural style used by 93.4% of APIs, found Postman’s 2020 State of API Report.

    GraphQL is promising and has a number of benefits, but remains in an early adoption phase. “It’s still a technology that early adopters are starting to look into—it’s not so widespread,” said Koren. Due to its age, GraphQL security practices are immature, exposing a few potential vulnerabilities for platforms that use GraphQL.

    Unique Security Concerns

    So, what are some unique security concerns in the GraphQL paradigm? Well, according to Koren, it begins with a lack of understanding. “Security is not necessarily top-of-mind most of the time,” he said. “When developers choose to implement GraphQL, they assume that they’re not using APIs anymore and that traditional REST API vulnerabilities do not apply.”

    In fact, the opposite may be true. GraphQL APIs can easily suffer from broken object-level authorization, OWASP’s number-one API vulnerability, just as REST APIs do. But, with greater ease of access to many underlying systems, a single GraphQL query could exfiltrate much more information than a typical API request. If the GraphQL provider does not have granular authorization checks for each particular method and resource, a GraphQL endpoint could suffer from data overexposure.

    Another issue concerns spotting malicious behavior. Typically, when hackers perform reconnaissance on an API, they brute-force it with many requests; trying different namespaces and changing user agents in the process. With REST APIs, this sort of malicious behavior is easier to catch with standard web application firewalls (WAFs) since it’s easier to notice hundreds of peculiar malformed requests. However, with GraphQL, a hacker conducting query batching could completely fly under the radar of typical thresholds.

    This could easily lead to an account takeover, said Koren, who has seen this in production. He described a production payment service that used GraphQL; callers could perform mutations and capabilities they shouldn’t have been allowed to perform, such as pulling up other users’ account information and even initiating transactions.

    It’s easier to limit this type of nefarious traffic with REST APIs by assigning access parameters to each resource and handling authorization checks once at a time. But, this playbook is thrown out the door in GraphQL. “When you’re using a single point to access the data, you may have some false sense of security,” said Koren. In practice, having a single access point requires hard work to retain its integrity. A usable GraphQL frontend may also often mask a convoluted backend made of disparate API styles, Koren explained, making it much harder to correlate user authorizations to specific resources and mutations across various microservices.

    Tips to Mitigate Weaknesses

    So, with these weaknesses in mind, how should GraphQL-based platforms respond? Koren provided the following advice to protect GraphQL APIs:

    • Adopt a security mindset in development: It’s vital to start with a security culture from the beginning. Usability shouldn’t compromise security; ideally, they should complement each other.
    • Ensure proper authorization checks are in place: Whenever an asset is provided to the user, you need to consider whether the user is authorized to access it—especially if they are hitting multiple resources at once.
    • Set a new baseline specific to GraphQL: GraphQL owners need to adapt their perimeter security systems to look for new queues. These validations should consider typical REST API security checks and nuanced thresholds that consider nested queries and batch queries.
    • Know your API inventory: Maintain a clear picture of the underlying architecture of what is beneath the GraphQL endpoint. Verify the data sources and ensure they correctly correspond to user privileges.
    • Increase visibility into API calls: If possible, increase your visibility into queries, mutations, attributes, variables and underlying specifications and how they interact with each other.

    Strengthening GraphQL Endpoints

    API attacks are rapidly increasing. Gartner estimates APIs will become a top threat vector in 2022, and Salt Labs data showcased a shocking 300% growth in malicious API traffic in mid-2021.

    “Like any other innovative tech that comes into the mainstream, it will rise in popularity, but it will not surpass REST in the foreseeable future,” says Koren. Perhaps in three to four years, GraphQL’s current 20% adoption rate will rise to 30% to 50%. While GraphQL is still a relatively niche tool, its use is growing, especially among API-first cloud-native tech companies. And with this adoption will come novel security concerns.

    According to Koren, query batching makes catching malicious attacks using ordinary firewalls tricky. Thus, training a new baseline to discover anomalies unique to GraphQL will be necessary to find and limit hackers while they are still in the reconnaissance phase. Thus, we’ll likely see future security investment go into spotting these atypical GraphQL interactions.

    In general, perhaps the best advice is to treat GraphQL with the same level of intensity you would with any other type of API—if not more. As a single doorway to many underlying systems, GraphQL requires added security forethought and careful application of user authorization.

    With that squared away, hopefully, GraphQL’s greatest strength will remain just that—a great strength.

  • Salt Security Adds Support for GraphQL APIs

    Salt Security Adds Support for GraphQL APIs

    Salt Security has extended its platform for securing application programming interfaces (APIs) to include support for APIs built using GraphQL.

    GraphQL is an open source data query and manipulation language for APIs that was originally developed by Facebook. It provides a more efficient approach to querying data than the REST APIs that are widely used today.

    Elad Koren, chief product officer for Salt Security, said adding support for GraphQL alongside existing support for REST APIs to the Salt Security API Protection platform will make it possible for security teams to discover those APIs, mitigate data exposure, stop attacks and eliminate vulnerabilities. The Salt platform parses the complex structure of each GraphQL query to identify unique object entities that are then used to create a complete inventory of the GraphQL APIs being employed.

    APIs built using GraphQL are more challenging to secure because of the unique call and response formats, noted Koren. Cybercriminals can also, for example, leverage GraphQL capabilities such as nested queries and query batching, to launch distributed denial of service (DDoS) attacks, he said.

    Many developers will tend to assume that, because GraphQL is relatively new, most cybercriminals are primarily focused on exploiting REST APIs. However, as more developers employ GraphQL, it’s only a matter of time before cybercriminals begin to find ways to exploit APIs that may not be as secure as the REST APIs that many organizations already know how to secure.

    The Salt Security platform itself is based on a big data engine that employs machine learning algorithms and other forms of artificial intelligence (AI) to identify attacks in real-time. It creates a baseline to identify legitimate system behavior while preventing cybercriminals from using penetration testing tools to perform reconnaissance.

    From a DevOps perspective, the Salt Security API Protection Platform integrates with tools such as Jira and Slack to ensure that remediation details are routed to the right development team in addition to helping track tickets to ensure remediation fixes are implemented. It also can be integrated with security information event management (SIEM) platforms from vendors such as Splunk and Sumo Logic to enable incident response for both DevSecOps and security operations teams.

    Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight. However, there will soon be enough APIs based on GraphQL to warrant additional security measures. Less clear is to what degree those security measures will be put in place by DevSecOps teams versus a security operations team.

    One way or another, however, the number of APIs that need to be secured is accelerating rapidly as organizations roll out a new generation of microservices-based applications that drive mission-critical digital business transformation initiatives. Each microservice has its own API that needs to be built and then secured. Unfortunately, most APIs are built by developers that don’t always have the greatest appreciation for security. As such, while more responsibility for API security is shifting left toward developers, many security teams would be well advised to make certain every API being deployed is fully secure.

  • What 30 Years of Linux Taught the Software Industry

    What 30 Years of Linux Taught the Software Industry

    Linux has become the largest collaborative development project in the history of computing over the last 30 years. Reflecting on what made this possible and how its open source philosophy finally imposed itself in the industry can offer software vendors valuable lessons from this amazing success story.

    The web may not have reached full adulthood yet, but it has already crafted its own mythology.

    August 25, 1991: Linus Torvalds, a 21-year-old university student from Finland, writes a post to a Usenet group: “Hello everybody out there using minix — I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386 (486) AT clones […]”. A few weeks later, the project, which will eventually be known as Linux, is published for the first time.

    This is the starting point of an epic that few could have foreseen.

    Fast-forward 30 years and the Linux kernel isn’t only running on most of the web servers and smartphones around the globe, but it also supports virtually all of the much more recent cloud infrastructure. Without open source programs like Linux, cloud computing wouldn’t have happened.

    Among the major factors that propelled Linux to success is security. Today, the largest software companies in the world are taking open source security to new levels, but the Linux project was one of the first to emphasize this.

    How Linux Became the Backbone of the Modern IT World

    Brief History

    Open source predates the Linux project by many years and is arguably as old as software itself. Yet, it is the success of the latter that propelled this movement in the 1990s. When it was first submitted for contribution in 1991 by Torvalds, the Linux kernel was the GNU project’s ‘missing link’ to a completely free software operating system, which could be distributed and even sold without restrictions. In the following years, and as the project started to incorporate proprietary licensed components and grow in popularity, a clarification on the meaning of “free software” became necessary.

    This led to the coining of the term “open source” as we use it today, thanks in part to Eric Raymond’s seminal paper The Cathedral and the Bazaar, a “reflective analysis of the hacker community and free software principles.” Open source was chosen to qualify software in which the source code is available to the general public for use or modification from its original design, depending on the terms of the license. People may then download, modify and publish their version of source code (fork) back to the community.

    Open source projects started gaining traction in the late nineties thanks to the popularity of software like Apache HTTP Server, MySQL and PHP to run the first dynamic websites on the internet.

    Facts and Figures

    Today, not only is Linux powering most of the digital era, but open source has become the leading model for how we build and ship software. Though most people don’t realize it, much of the technology we rely on every day runs on free and open source software (FOSS). Phones, cars, planes and even many cutting-edge artificial intelligence programs use open source software. According to the Linux Foundation, 96.3% of the world’s top one million servers run on Linux and 95% of all cloud infrastructure operates on it. Other infrastructure also relies on open source: 70% of global mobile subscribers use devices running on networks built using ONAP (Open Network Automation Platform).

    Linux adoption is very high in professional IT, where it’s become a de facto standard, especially with the advent of the cloud era. In fact, 83.1% of developers said Linux is the platform they prefer to work on. This success is due, in large part, to the community that contributed to its source code since its creation: More than 15,000 developers from more than 1,500 companies. Linux went on to become, arguably, the biggest success story of the free software movement, proving that open source could lead to the creation of software as powerful as any sold by a corporation.

    The Linux Foundation, a non-profit technology consortium founded in 2000 to support the collaborative development of Linux and OS software projects, is itself a big success. It now has more than 100 projects under its umbrella, spread across technology sectors like artificial intelligence, autonomous vehicles, networking and security. Several subset foundations have also emerged over the years, including the Cloud Foundry Foundation, the influential Cloud Native Computing Foundation, and the recently announced Open Source Security Foundation. The Foundation estimates the total shared value created from the collective contributions of its community to a whopping $54.1 billion.

    All these achievements may not have been possible without the embrace of open source by the enterprise world, which may represent its biggest win.

    Enterprise Adoption

    Companies began to realize that many open source projects were easier and cheaper to implement than asking their developers to build the basic pieces of an internet business over and over again from scratch.

    Twenty years ago, most businesses ran atop proprietary software from Microsoft, Oracle and IBM, and the idea of collaborating on big software projects might have sounded laughable to them. Today, these companies, along with relative newcomers such as Google, Facebook and Amazon, are not only employing thousands of full-time contributors to work on open source projects like Linux, they also regularly choose to open source some of their state-of-the-art projects; from Google Brain’s machine learning platform TensorFlow and container orchestration platform Kubernetes to Facebook’s React.

    There’s no question that open source software created a new wave of business opportunities. As more companies took an interest in open source projects, they realized they didn’t necessarily have the in-house expertise to manage those projects themselves and turned to startups and larger companies for help.

    Even Microsoft, which famously warred against the very concept of Linux for nearly a decade, made a strategic shift to embrace open source in the 2010s, led by CEO Satya Nadella. The IT giant finally joined the Linux Foundation in 2016 and acquired GitHub, the largest host for open source projects, two years later. It has since become one of the biggest sponsors of open source projects.

    As a consequence, the stakes have been raised for open source software, which is the engine powering the shift toward the cloud for virtually every company. In this context, security is becoming a topic of the utmost importance, and the commitment to secure the open source ecosystem is growing fast.

    Setting a Standard for Security and Trust

    Open Source Security Issues

    Following the OSS adoption boom, the sustainability, stability and security of these software packages is now a major concern for every company that uses them.

    The Census II report on structural and security complexities in the modern-day supply chain “where open source is pervasive but not always understood” revealed two concerning trends that could make FOSS more vulnerable to security breaches. First, the report said it is common to see popular packages published under individual developers’ accounts, raising the issue of security and reliability. Second, it is very common to see outdated versions of open source programs in use, meaning they contain fewer security patches.

    The 2021 OSSRA report agrees: “98% of the codebases audited over the past year contain at least one open source component, with open source comprising 75% of the code overall.” The report also noted that 85% of the audited codebases contained components “more than four years out of date”.

    This highlights the mounting security risk posed by “unmanaged” open source: “84% of audited codebases containing open source components with known security vulnerabilities, up from 75% the previous year. Similarly, 60% of the codebases contained high-risk vulnerabilities, compared to 49% just 12 months prior.” Not only is the security posture affected, but there are also compliance issues that can arise from unsupervised integration of open source content because licenses can be conflicting or even absent.

    Because large corporations are now a big part of the open source ecosystem, their sponsorship is a welcome source of financing for many people whose work had been done for free until now, yet it may not be enough. The open source community is well-known for its commitment to independence, its sense of belonging and its self-sufficiency, and expecting contributors to voluntarily address security issues is unlikely to succeed.

    This is where the experience of building Linux over 30 years and coordinating the work of thousands of individual contributors may be an example to follow.

    Linux Foundations

    In Linux kernel development, security is taken very seriously. Because it is an underlying layer for so many public and private software ‘bricks’ in the digital world means that any mistake can cost millions to businesses, if not lives. Since the beginning, it has adopted a decentralized development approach with a large number of contributors collaborating continuously. Therefore, it has consolidated a strong peer-reviewing process as the community development effort grew and expanded.

    The last stable release at the time of writing is 5.14, released on August 29th, 2021, only a few days before the 30th birthday of the project. The most important features in the release are security-related: One is intended to help mitigate processor-level vulnerabilities like Spectre and Meltdown and the other concerns system memory protection, which is a primary attack surface to exploit. Each Linux kernel release sees close to 100 new fixes per week committed by individuals and professionals from the likes of Intel, AMD, IBM, Oracle and Samsung.

    With such broad adoption and long history, the Linux project has reached a level of maturity that few, if any, other FOSS projects have seen. The review process and release model have built confidence for numerous downstream vendors. Although the world is not perfect and it is arguably difficult for them to keep up with such a high rate of change, they can at least benefit from strong security enforcement mechanisms and they can adapt their security posture in concordance to their “risk appetite”: Vendors are able to do the calculus of determining how old a kernel they can tolerate exposing users to.

    Pushing the Boundaries of Open Source Security

    Heartbleed and the Fragility of OS Security

    In April 2014, a major security incident affecting the OpenSSL cryptography library; disclosed as “Heartbleed.” The developer who introduced the bug acknowledged that, though he was working on the project with a handful of other engineers:

    “I am responsible for the error because I wrote the code and missed the necessary validation by an oversight. Unfortunately, this mistake also slipped through the review process and therefore made its way into the released version.” OpenSSL, an open source project, is widely used to implement the Transport Layer Security (TLS) protocol. In other words, it’s a fundamental piece used to secure a large part of the web.

    Open source was seen as fundamentally secure for a long time because the more people examine a line of code, the better the chances of spotting any weakness. Additionally, this model prevents “security by obscurity,” whereby the bulk of the protection comes from people not knowing how the security software works—which can result in the whole edifice tumbling down if that confidential information is released or discovered externally.

    This incident was a major turning point for a large share of the biggest web corporations: They realized that many open source technologies underpinning their core operations could not be “assumed to be secure” anymore. Any human error could have huge implications; therefore, a specific effort had to be made to improve the security in this specific space.

    A New Era for Open Source

    As we advance in an era where open source is omnipresent in codebases, tooling, networks and infrastructure and is even in fields other than software, security awareness is starting to take hold. But it needs a lot more work.

    A big part of the challenge, to begin with, is for the industry to understand the scope of the problem.

    Google just announced that it will be committing “$100 million to support third-party foundations that manage open source security priorities and help fix vulnerabilities.”

    The Secure Open Source (SOS) pilot program, run by the Linux Foundation, will reward developers for enhancing the security of critical open source projects that we all depend on.

    In doing so, Google leads the way in enlarging the financial sponsorship of big players like companies and governments — which are increasingly sponsoring open source both directly and indirectly. However, they also recommend that organizations “understand the impact they have on the future of the FOSS ecosystem and follow a few guiding principles.”

    What could these principles look like?

    A Roadmap to Safely Use and Contribute to Open Source

    The Linux Foundation proposed a specific Trust and Security Initiative which describes a collection of eight best practices (with three degrees of maturity) open source teams should use to secure the software they produce as well as by a larger audience to “raise the collective security bar.” Here they are:

    • Clarifying the roles and responsibilities, and making sure everyone is aware of their security responsibilities across the organization.
    • Setting up a security policy for everyone; in other words, a clear north star for all members of the organization.
    • ‘Know your contributors’ is defined as a set of practices to make risk-based decisions on who to trust and fight offensive cyberwarfare techniques, such as the poisoning of upstream code.
    • Locking down the software supply chain: This has become a preferred target as adversaries clearly understood that they can have a bigger and more effective impact with less effort than targeting individual systems.
    • Provide technical security guidance to narrow potential solutions down to the more appropriate ones in terms of security.
    • Deploy security playbooks to define how to do specific security processes, specifically incident response and vulnerability management processes, like creating roles and responsibilities or publishing security policies. This may feel formal, antiquated and old-school but having pre-defined playbooks means that teams can focus on shipping software and not learning how to do security, especially at the least convenient and most stressful time.
    • Develop security testing techniques with automated testing strongly recommended since it scales better, has less friction and less cost to the teams and aligns well to modern continuous delivery pipelines.

    However, the authors of the guide are aware that some major challenges are still facing the industry and, as such, need to be addressed. They mention:

    • The lack of open source security testing tools
    • The fact that open source package distribution is broken
    • The fact that the CVE format for vulnerability disclosure is also broken
    • The lack of a standard for a security build certificate which would allow any consumer to transparently verify that a product or component complies with the announced specifications

    “The types of verification can and should include the use of automated security tools like SAST, DAST and SCA, as well as verification of security processes like the presence of security readmes in repos and that security response emails are valid.”

    A scheme like this could have a significant and lasting effect on the security quality of open source software and the internet at large.

    The Linux project, born 30 years ago, is present in all layers of the modern software stack today. It is used by all the largest server clusters powering the modern web and any business going digital will use it at some point. This unparalleled longevity and success have demonstrated that the open source model was compatible with the requirements of enterprise-grade services and economically viable. Now that open source is all the rage in the software industry, a consensus and action plan on how to ensure the sustainability of this ecosystem becomes urgent. The top priority for businesses that depend on it is to adopt strong application security guidelines, like the ones promoted by the Linux Foundation, which have proven their value.

    One last note on the nature of open source: As businesses are now much more bound by the common use of open source components to build upon, they should not fall into the “tragedy of the commons” trap. This would mean waiting until others take action; for instance, to improve the global software security landscape. This might be one of the biggest challenges confronting our highly collaborative industry.

  • BMC Looks to Advance ServiceOps Approach to Managing IT

    BMC Looks to Advance ServiceOps Approach to Managing IT

    During an online BMC Exchange event, BMC announced it expanded its portfolio of IT management offerings as part of an ongoing effort to unify traditional IT service management and DevOps processes under an integrated ServiceOps framework.

    The latest additions to the BMC portfolio includes an update to its Control-M workload automation platform that adds observability tools for monitoring application and data workflows along with additional integrations for cloud services such as AWS Glue, Google Cloud Dataflow and Function and Microsoft Azure Data Factory and platforms such the data lake from Databricks.

    BMC is also making available a preview of a Control M Python client that will extend the reach of the workload automation platform to the code data science teams employ to build artificial intelligence (AI) models.

    In addition, BMC is adding a BMC Helix Digital Workplace studio to make it easier for IT teams to customize the software-as-a-service (SaaS) platform it provides for IT service management (ITSM). Finally, BMC is also making available a version of BMC Helix that is optimized for communications service providers.

    BMC CEO Ayman Sayed said overall the current emphasis on digital business transformation is driving a need to converge the management of multiple IT platforms as organizations reinvent how core processes work across their organization. It’s not possible to drive that level of reengineering across multiple IT platforms without centralizing the management of those platforms using a ServiceOps framework that unifies DevOps and existing ITSM platforms, he noted.

    At the same time, Sayed said organizations need to invest more in artificial intelligence to automate IT operations, also known as AIOps, to augment IT staff that is hard-pressed by the need to manage both emerging and legacy IT platforms. The latest investment BMC has made in AIOps came earlier this month with the acquisition of StreamWeaver, a provider of a set of tools that make it easier to collect massive amounts of data that can be used to more easily train AI models.

    It’s too early to say to what degree IT management processes might become unified. In addition to centralized IT teams, most organizations have business units that often drive their own IT initiatives. However, as organizations realize how many platforms a digital process needs to access the need to centralize the management of IT becomes more apparent. The issue each organization will need to determine is the degree to which that centralization needs to occur.

    It’s clear in the wake of the COVID-19 pandemic that many IT organizations have never been more agile. In some cases, those IT teams are now able to drive a rate of change that is too fast for many businesses to even absorb. In fact, it’s arguable that entire businesses will need to adopt DevOps principles to manage that rate of change.

    In the meantime, IT teams will need to take a harder look at how much time is being spent on manual tasks that could be automated in a way that enables them to be lot more productive than they are today.

  • InfluxData Simplifies AppDev for Time-Series Databases

    InfluxData Simplifies AppDev for Time-Series Databases

    During an online InfluxDays North America 2021 Virtual Experience conference, InfluxData today expanded the capabilities of its application development tools using its Flux query language on top of its time-series database.

    The company has enhanced its InfluxDB Notebooks tool to enable developers to quickly set up an alert, build a task or write a Flux script without having to leave their browser.

    In addition, developers can compose Flux queries to be included in client code that can then be autogenerated within applications written in more than 10 different programming languages. There is now also an extension of Visual Studio Code that makes it simpler to create Flux scripts, query InfluxDB, create Flux tasks and manage buckets.

    Finally, InfluxData added the ability to explicitly define the schema of a bucket within InfluxDB to safeguard against unwanted changes; an application programming interface (API) tool, dubbed API Invocable Scripts, to make it simpler to define parameterized Flux scripts and the ability to send notifications from Alerta, WebEx Teams and ServiceNow to the InfluxDB Cloud platform.

    Tim Hall, vice president of product for InfluxData, said the overall goal is to reduce the level of complexity developers encounter when building applications that run on a time-series database. Many of those applications are now core to digital business transformation initiatives that require data to processed and analyzed over time. In effect, time-stamped data adds yet another dimension to any application, noted Hall.

    Time-series databases are typically employed by either an independent software vendor (ISV) to create, for example, a monitoring application, or an enterprise IT team that is building an application that lends itself to data that needs to be tracked over some period of time.

    In most instances, applications built on a time-series database are being deployed alongside, for example, relational databases that are generally invoked using SQL. As a result, InfluxDB has made it simpler to join data across relational and time-series data via SQL integrations the company added to Flux, noted Hall.

    DevOps teams, of course, are not always anxious to add another database they need to support, but as applications continue to evolve, more organizations are employing a mix of purpose-built databases to develop applications as the volume of data that organizations are trying to manage and analyze continues to grow.

    In the longer term, it’s clear time-series databases will play a critical role in driving digital business transformation initiatives. The challenge most organizations are now struggling with is determining which of these initiatives to prioritize. A time-series database coupled with the developer tools provided by InfluxData will enable IT teams to build the applications that drive those processes much faster, said Hall.

    In the meantime, IT teams would be well advised to at least become more familiar with time-series databases, because knowing the time when an event occurred is becoming a bigger application requirement. After all, knowing when something happened is now just as important as the record of what actually occurred.

  • Eclipse Foundation Launches Open Source Edge Computing Initiative

    Eclipse Foundation Launches Open Source Edge Computing Initiative

    The Eclipse Foundation in collaboration with the OpenAtom Foundation today launched the Oniro project and working group to create an independent implementation of OpenHarmony, an open source operating system.

    Created by the OpenAtom Foundation, the OpenHarmony operating system is based on a HarmonyOS originally created by Huawei. It is designed to support multiple kernels but uses the Linux kernel if a device has a large amount of memory.

    It also includes a DSoftBus capability for integrating physically separate devices into a single logical super device that enables one device to control others in addition to facilitating data sharing among distributed devices.

    Huawei, in collaboration with Linaro, Seco, Array, NOITechPark and Synesthesia, has also been contributing to a continuous integration/continuous delivery (CI/CD) platform that is part of the larger Oniro project.

    Mike Milinkovich, executive director of the Eclipse Foundation, said the goal is to provide a common layer of abstraction platform that can be employed across a wide range of embedded systems that are typically being deployed at the network edge. That level of fragmentation surrounding platforms that don’t provide a lot of significant differentiated value only results in slowing down the deployment of applications, noted Milinkovich.

    As part of that effort, a dedicated working group has been created to provide a vendor-neutral structure through which contributions to the project can be made with greater transparency. The OpenAtom Foundation was created in Beijing last year with the support of Alibaba, Baidu, Huawei, Inspur, Qihoo, Tencent and China Merchants Bank. The alliance with the Eclipse Foundation brings more traditional governance rules for building open source software to the OpenHarmony project.

    In general, DevOps teams should be tracking the development of proposed de facto standards for edge computing platforms closely. More applications are now being deployed on edge computing platforms that make it possible to process and analyze data at the point where it is being created and consumed. The DevOps challenges associated with building and deploying applications across a highly distributed computing environment are considerable.

    In many cases, organizations that never really attempted or mastered continuous delivery of applications and their associated updates will be sorely challenged when it comes times to support hundreds, possibly thousands of applications, running on embedded systems based on a wide range of processors.

    In addition, many of those same DevOps teams will start to see traditional batch-oriented applications being superseded by applications based on event-driven architectures that process data in near-real-time. In most cases, those applications are going to be built on microservices-based applications that are typically more challenging to build and deploy than a traditional monolithic application.

    Arguably, IT organizations are on the cusp of a new era of IT that assumes most organizations have not only mastered DevOps best practices but are now also embracing DevSecOps best practices to secure those application environments.

    It may be a while before the open source software that will be developed by the Orino project finds its way into production environments, but it should be apparent that reducing complexity at the network edge should be a high priority for all DevOps teams heading into 2022.

  • AsyncAPI: Transparency as a Value

    AsyncAPI: Transparency as a Value

    History has been marked by opaque and totalitarian power systems. Aided by prisons and walls that keep out the light. The concentration of power in the hands of a few individuals has marked human evolution. From feudalism to fascism, the annulment of the rights of individuals has been based on obscurantism and ignorance. Information has always been guarded by a few, in a few places, and under lock and key. Darkness was always understood as the opposite of knowledge, of science. Plato referred to the cavern, the place where shadows are barely glimpsed, distorted, manipulable from the outside. Subjected to the opacity of the camera obscura, we live in the hope of a shutter that will open a first light bulb.

    Fighting the One-Dimensional

    Faced with the danger of control and censorship, of single direction, of what Marcuse would end up calling “one-dimensional man”, the new tools born at the end of the 20th century cracked the traditional foundations on which power was based. The expansion of the internet offered an opening of windows to the world, the multiplication of paths. The entry of light into every home in the form of a seemingly infinite torrent of information, impossible to censor, unfathomable.

    The arrival of Society 2.0 marked the definitive turning point in government systems toward a necessary democratization. Under its premises, nothing can or should be hidden; everything is potentially visible. Moreover, there are no longer spectators who attend the show, but users appear ready to add their grain of sand in a collective bet, to open their shutter to let in some more light.

    The Spotlight

    The involvement and activation of users is the strength of a collective intelligence. The multiplication of images uploaded by users makes manipulation more difficult, broadens the options for contrasting perspectives and opinions. They add lines of writing to an amplified story.

    The user thus becomes a spotlight that avoids blind spots. One more flashlight at the service of the common good. For the image of a transparency, a slide, for example, to be projected on the wall, we need a light source directed toward the acetate, thus allowing us to see the intricacies of an image that remained in the dark until that moment.

    Disclosure

    Transparency has probably become the fundamental concept of the democratization processes undertaken by governments, institutions and companies in recent years. Ultimately, in its ideal state, democracy is nothing more than a method that allows the members of a community to analyze reality from different points of view to finally make decisions.

    From all this arises open source policy, a system that makes information free and at the same time allows users to see its management and decision-making processes and in which everyone is invited to collaborate. The community thus becomes an essential engine of work and communication.

    The Light

    AsyncAPI arises from this foundation. As an open government project, it defends transparency and democratization in its system of governance and organization. This organizational system aims to empower the people who make up the project, based on a horizontal structure for decision making.

    All relevant project data are public. The tasks under development are within the reach of and open to participation by the community. This is intended to cultivate an environment of trust and respect for the user that stimulates their participation in the pursuit of a common goal. This allows projects to be increasingly collaborative and participatory. Data and metadata. Code and image. As digital photography does, it is no longer possible to attend only to the final state, to the superficiality of the image that is shown, edited, composed, manipulated. The image becomes an open, transparent process, where we can compare its properties, its internal structure.

    Finally, the light.