Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Warren Buffett asks too much for wind energy, it’s “completely ridiculous” to say Google’s chatbot LaMDA is sentient, and Microsoft finally kills Internet Explorer. (more…)
A global survey from ReversingLabs found 87% of respondents agreed that software tampering has become a more frequently-used cybersecurity attack, but only 37% said they have any means to detect it.
The survey, which polled 300 IT and security professionals, was conducted by Dimensional Research on behalf of ReversingLabs, a provider of a platform for analyzing any file, binary or object. Despite software tampering’s frequency, only 7% of survey respondents said they could detect software tampering at each phase of the software development life cycle.
Just as troubling, only slightly more than half (51%) reported being able to protect their software supply chain with only a third being able to actually check for tampering once an application is final and deployed, the survey found.
Overall, more than half of respondents (54%) said their organization knowingly released software with potential security risks. Nearly every respondent (98%) also acknowledged that reliance on third-party software use, including open source software, increases security risks.
On the plus side, more than three-quarters of respondents (77%) said they appreciated the value of a software bill of materials (SBOM) that makes it possible to ascertain what software artifacts are being employed within an application. However, only 27% of respondents said their organization currently generates and reviews SBOMs. A full 90% said they are finding it increasingly difficult to create and review SBOMs. Nearly half of the survey respondents reported that SBOM processes today involved manual steps.
Other SBOM hurdles respondents cited included lack of expertise (44%) and inadequate staffing to review and analyze SBOMs (44%).
ReversingLabs CEO Mario Vuksan said that while it’s still early days as far as SBOM capabilities are concerned, a series of high-profile zero-day vulnerabilities has forced the issue into the spotlight. Organizations are now spending months looking for every possible instance of newly discovered vulnerabilities because no one is quite sure what application components are running across an extended enterprise, he noted.
However, as DevSecOps best practices continue to evolve and mature, it’s also clear that SBOMs will play a critical role in securing software supply chains, Vuksan added. The challenge is that in the age of microservices, application environments are now much more dynamic as components are ripped and replaced with greater frequency, he added.
SBOMs, of course, are just one element of what will be required to secure a software supply chain. Many organizations are now reviewing their software development processes and uncovering uncomfortable truths about how software is currently built and deployed. The ultimate goal is not to slow down the rate at which software is developed but to make sure there are guardrails in place that prevent insecure software from being deployed in the first place. Far too many developers today still view cybersecurity reviews as tasks to be avoided in the name of meeting an application deployment deadline.
Hopefully, that won’t continue to be the case as more responsibility and accountability for applications security shifts left toward developers and DevOps teams. In the meantime, however, when it comes to application security, it’s apparent there’s still much room for improvement.
Jit today emerged from stealth with a free namesake orchestration platform beta that automatically implements security plans as code.
Aviram Shmueli, chief product officer for Jit, said the company will both make security plans it developed available as code within GitHub. In addition, Jit will make available a service through which customers can submit documents and spreadsheets that Jit will convert into a custom security plan that can be executed as code.
Fresh from raising $38.5 million in seed funding, Jit is aiming to advance the adoption of DevSecOps best practices by enabling cybersecurity policies to be more easily implemented as code via its orchestration platform, said Shmueli. The Jit platform enables developers and DevOps teams to take advantage of a graphical tool to automatically implement security policies within a DevOps workflow with a single click, he noted.
The goal is to eliminate the need for separate DevOps teams to create security policies that each would need to individually manage, added Shmueli.
In theory, DevSecOps best practices require shifting left the responsibility for security toward application development teams. The challenge is that development teams generally don’t have the expertise required to craft effective cybersecurity policies. Jit is making a case for a platform that makes it simpler to automatically implement vetted cybersecurity policies.
Exactly how far responsibility for application security will shift left remains to be seen. Developers generally prefer to spend as much time as possible creating business logic rather than implementing cybersecurity policies. As such, it’s frequently left to a DevOps team to find a way to consistently implement cybersecurity policies across multiple applications. Each DevOps team will need to decide how much they can rely on the policies defined by Jit versus opting to implement a set of policies defined by their internal cybersecurity teams. The issue that often arises is cybersecurity teams lack programming skills; the only means available to define cybersecurity policies is some type of document or spreadsheet that, one way or another, needs to be converted into code.
Given the ongoing chronic shortage of cybersecurity expertise, it’s apparent that more efficient methods for sharing cybersecurity best practices are required at a time when application environments continue to both rapidly expand and increase in overall complexity.
Regardless of the DevSecOps approach, the pressure to address application security is mounting in the wake of a series of high-profile cybersecurity breaches. Organizations of all sizes are now reviewing software supply chains that are increasingly being targeted by cybercriminals. Security policy-as-code tools make it possible to ensure that applications don’t, for example, communicate with an external system without express permission.
One way or another, the level of application security currently being attained will improve in the months ahead as more mandates are enforced. The only real issue remaining is the amount of disruption to existing processes that will be required to achieve that goal.
At its .conf22 event, Splunk today announced it is making it easier to both onboard data and then manage it across hybrid IT environments via the Splunk Cloud Platform.
In addition, Splunk Enterprise is being extended to add support for Microsoft Azure with SmartStore for Azure to store cold data alongside existing support for Amazon Web Services (AWS) and Google Cloud Platform (GCP). There is also a developer edition of Splunk Cloud that enables developers to create and test their own applications, which is currently in preview.
Garth Fort, senior vice president and chief product officer for Splunk, said the overall goal is to make it easier to automatically tune the parameters used to store data in the Splunk observability platform. As more organizations embrace observability as a DevOps best practice, many of them are encountering challenges managing the large volumes of data they are now collecting in the form of logs, metrics and traces.
The Data Manager for Splunk Cloud Platform will initially be made available on AWS and Azure, with support for GCP to come later this summer. In effect, it provides IT teams with a control plane for data management that spans multiple clouds.
Ingest Actions, meanwhile, makes it possible to apply granular controls that enable IT teams to filter, mask and route data in motion within the Splunk Platform or to external AWS S3 cloud storage services.
Other capabilities Splunk unveiled at the conference include an expansion of Federated Search tools to enable a single pane of view across their entire Splunk ecosystem and a fully managed Splunk Assist service for Splunk Enterprise 9.0 that provides customers with deep insights into their security environment.
Finally, the company has enhanced Splunkbase, a framework for accessing curated collections of more than 2,500 applications and integrations provided by Splunk and its third-party partners.
As the pioneer of IT operations analytics, Splunk has a large footprint within enterprise IT environments. It is now looking to expand that base to become an observability platform provider. It’s still early days as far as the transition to observability is concerned, but the goal is to make it simpler for IT teams to query platforms and surface issues that could lead to an IT disruption before it happens.
It’s not clear how many organizations have the skills and expertise required to formulate those queries, but over time it should become more feasible to augment an IT staff with machine learning algorithms capable of discovering those issues.
In the meantime, IT organizations are collecting more data than ever about their IT environments. In theory, that data will provide the context needed to optimize application environments that get more complex with each passing day. The challenge, of course, then becomes finding a way to efficiently store and manage all that data both before and after it has been analyzed.
Regardless of the approach to observability, the need to go beyond simple monitoring of IT environments has never been more apparent.
Companies are under mounting pressure to continuously release new applications and features. And as software development life cycles become more iterative, continuous integration and continuous delivery (CI/CD) has become a necessary ingredient to enable more rapid deployments.
Many development teams now embrace DevOps, but fully automating a CI/CD pipeline from source code to production deployment is no easy task. For one, the number of tools in use continues to balloon, meaning CI/CD poses an ongoing maintenance hurdle. Furthermore, CI/CD tools often adopt varying formats to describe their events. A CI/CD pipeline, a form of event-driven architecture, may require a lot of special “glue” to patch events together if the output from each tool is not in a standardized format.
Interestingly, CDEvents, an emerging open source standard from the Continous Delivery Foundation (CDF), is working to standardize the root semantics of how CI/CD tools describe the payloads of their events with more granularity than CloudEvents. The project aims to establish schemas for how common CI/CD events are described, easing integration and providing more actionable data surrounding the CI/CD pipeline.
I recently met with Andrea Frittoli, open source developer advocate at IBM, to understand why the CDEvents project exists, how it works and what they’re hoping to achieve. According to Frittoli, who is also co-creator of the CDEvents project and a member of the CDF Technical Oversight Committee, CDEvents has the potential to bring much-needed interoperability to the sprawling CI/CD tooling ecosystem. Below, we’ll investigate where the project is and consider where it’s heading.
At its core, the problem CDEvents is trying to solve is a lack of interoperability in the CI/CD field, explained Frittoli. As it stands today, DevOps engineers must routinely make point-to-point integrations between CI/CD tools. “No single tool will take you entirely from managing source code to production,” he said. A single development team could be using up to 15 unique components in one pipeline, and tooling preferences can vary dramatically across teams, he adds, further complicating CI/CD interoperability.
Although CloudEvents has made inroads as a specification to describe event data, nothing has yet existed specifically for describing CI/CD events. According to Frittoli, CloudEvents falls short here, as it’s agnostic about what is inserted into the payload.
CDEvents is “a common specification for Continuous Delivery events.” Frittoli describes it as a shared dictionary or shared semantics for common events. These events could be a change in source code, running a test, or a code execution or deploy. CDEvents uses JSON object schemas to describe the event types and can work alongside CloudEvents as an attribute. “CDEvents is a standard format for the payload as well, not only for the envelope,” said Frittoli.
As Frittoli explains, the CDF special interest group is still drafting the CDEvent specification’s exact semantics and common names. Currently, CDEvent organizes these objects into four main buckets: Core events, source code version control, CD events and CI events.
While the group is still finalizing the format of events as they work toward the initial release, the example below is an approximation of what the final format will look like:
"meta": {
"version" : "draft",
"event_id" : "A234-1234-1234",
"source" : "/staging/tekton/",
"type" : "dev.cdevents.taskrun.started",
"timestamp" : "2018-04-05T17:31:00Z"
},
"subject": {
"id": "/namespace/taskrun-123",
"type": "taskrun",
"content": {
"URL": ...
"pipelinerun": ...
}
},
"extensions": [{
"name": ,
"content": ...}
],
"links": [{
...
}]So, why is it necessary to define the format of CI/CD event data? What benefits does this bring to developers and the business as a whole? Well, Frittoli sees two potential primary use cases. First off, CDEvents could reduce the effort spent writing and maintaining glue code between common DevOps tools like Spinnaker, Argo or Flux. “This will allow a smoother integration between all the parts,” said Frittoli. Alleviating this could help scale CI/CD initiatives and increase overall agility.
Another positive side effect is collecting more detailed information about workloads and their performances. If all these components generate similarly-formatted events, Frittoli explained, then you can begin to create a true end-to-end visualization of the entire CI/CD pipeline. Then, you can start to measure things such as deployment frequency, failure rate, time to change and other metrics.
If events begin to use a common language, you could do many interesting things with that data, says Frittoli. Event data could help ascertain the root cause of incidents and aid debugging. One could even foresee some AIOps potential to further automate operations and increase observability around CI/CD.
CDEvents emerged at a time when iterative software development has become commonplace. A slew of helpful CI/CD tools is at our disposal to enable niche operations. Yet, the space still requires a standard way to operate between them. CDEvents is an exciting prospect, yet the project is still in its early stages. It has yet to reach a full release or any production use and proofs-of-concept are still being developed.
Of course, encouraging a vendor-neutral specification requires the tooling community to get on board. “It’s vital for the different tools to implement CDEvents for it to be successful,” said Frittoli. He encourages the tooling community to join the working group to collaborate in building proofs-of-concept. The SIG plans to continue working on finalizing the first version of the specification. In the meantime, the group has produced a proof-of-concept using Tekton and keptn and the project has its future sights set on Knative and Jenkins.
The CDEvents project is in incubating mode and maintained by the Events Special Interest Group (SIG) at the CDF. For more information, you can peruse the CDEvents documentation here or become involved with the community here. The Events SIG also holds biweekly meetings and a CDEvents Community Summit will be part of the upcoming CDcon.
The Eclipse Foundation this week opened an Adoptium Marketplace through which DevOps teams can access Java binaries based on the OpenJDK specification. OpenJDK was created based on the Java standard edition (SE) of the programming language and virtual machine.
Mike Milinkovich, executive director of the Eclipse Foundation, said the goal is to make it easier for IT teams to access open source binaries via a vendor-neutral marketplace that complies with the Java SE Technology Compatibility Kit (TCK) that was created to make sure runtimes based on OpenJDK conform to the original Java specification.
The marketplace has been set up in collaboration with the Adoptium Working Group that was set up by the Eclipse Foundation to govern OpenJDK, an open source implementation of the Java SE originally created at Sun Microsystems and later acquired by Oracle.
Members of The Adoptium Working Group include Alibaba Cloud, Azul, Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic and Red Hat. That group created an Eclipse AQAvit project to test binaries for compliance with the Java SE TCK specification.
OpenJDK is a reference implementation used by multiple vendors to create their own binaries, which are only guaranteed to be compatible with the standard until the next update arrives; updates are released approximately every six months. The Eclipse Adoptium project will make it simpler for developer teams to identify which binaries are compatible with specific implementations of OpenJDK. Ultimately, the goal is to encourage developers to build applications using frameworks that make use of new OpenJDK features as they are added to the platform versus continuing to rely on older binaries.
Java remains the dominant language for developers working in enterprise IT organizations. Over the last few years, however, OpenJDK has gained traction as organizations adopted an open source implementation of the specification that enabled providers of application development frameworks to reduce licensing costs.
It’s not clear at what rate enterprise IT organizations are replacing proprietary editions of Java with OpenJDK. However, during an economic downturn, more organizations tend to rely on open source software. Many organizations are also now looking to build microservices-based applications using Java frameworks based on OpenJDK runtimes.
It’s obviously taken quite a bit of time for the OpenJDK community to put together a vendor-neutral marketplace. In the meantime, a wide range of other programming languages gained traction in the enterprise. There is still a lot of dependency on Java for building backend applications and services, but it’s more common than ever to see frontends that access those backend applications and services being built using, for example, a framework based on JavaScript.
Java, of course, isn’t going away any time soon. The sheer number of enterprise developers that rely on it to build applications will ensure its continued longevity. The important thing to note, however, is that as more open source platforms are employed, the pace at which the overall community will innovate should continue to accelerate.
Observability platforms that unify metrics, logs and traces across applications and IT infrastructure are transforming how IT is managed. Most DevOps teams today are able to continuously monitor IT environments using tools that track a set of pre-defined metrics; observability platforms make it possible to aggregate data so that DevOps teams can launch queries that help them uncover the root cause of IT issues. DevOps teams leverage observability to allow them to understand what is happening within their applications more effectively and efficiently.
Historically, applications were black boxes—meaning it was (and still is, in many cases) extremely difficult to know what is happening under the hood of the application.
With the advent and subsequent growth of observability tools and techniques in the DevOps space, teams went from struggling to collect and understand the available data (which could vary from robust to almost non-existent) to easily aggregating data from numerous sources and being able to understand what that data means to being completely deluged with data—so much data it’s hard to keep up.
Josh Chessman, vice president of strategy and innovation at IT infrastructure monitoring specialist Netreo, explained that as applications become more and more complex, (e.g., running across multiple disparate environments with different technologies and in different locations) being able to collect data from these different environments is no longer enough.
“Instead, DevOps engineers need to be able to collect the data and efficiently analyze it, too, to understand what is happening within the application,” he said. “Observability is the concept that drives this.”
Chessman pointed out there are numerous observability issues DevOps teams face, but that they vary from organization to organization (and sometimes from team to team within an organization).
“Part of the problem is that many organizations simply lack tools to provide the data collection and analysis needed to move to an observability paradigm,” he said.
This could be for numerous reasons, including budget (if you already have an existing tool, can you afford to acquire a new tool?), functionality (not all tools that claim to provide observability really do), implementation (this stuff is not easy and a poorly implemented tool could actually make things worse) and more.
“One of the larger challenges I’ve seen is that organizations will go out and acquire an ‘observability’ tool and assume that is all they have to do,” Chessman said. “Unfortunately, that is not the case. Acquiring the tool gets you the technology, but the team must also be structured and ready to take advantage of the concepts and functionality provided by the tool.”
GitLab’s senior director of product management Kenny Johnston explained that, on average, DevOps teams use five different observability tools which tend to inadequately connect developers to observability.
In turn, developers struggle to respond to incidents swiftly while jumping across multiple tools and sources of truth and struggle to assign service level objectives (SLOs) and error budget definitions to the responsible product development teams.
“To remedy this, we recommend adopting a unified software development solution that replaces the DIY ‘duct tape’ of products constraining developers and helps them deliver software more securely, at speed and scale,” he said.
Johnston said the most flexible and future-proof solutions today are open source tools like Prometheus and its ecosystem, as well as the OpenTelemetry toolset for more advanced use cases such as tracing.
Prometheus has become very common in the developer space and, unlike other open source solutions or libraries, its format automatically emits metrics.
“This allows for simple and future-proof interoperability, as one of the hardest things to change later down the line is code running,” he said. “Using open standards reduces the need for developers to rewrite and reintegrate the same type of code over and over again.”
From Chessman’s perspective, understanding what your goals are is critical for observability.
“Observability tools can do many things, but their primary function is to collect and analyze data,” he said. “While that is all well and good, if you do not define your KPIs from the beginning, all the collected and analyzed data is meaningless since you have no concept of what good and bad are.”
Trying to define good and bad from the data collected is likely to result in failure because you are looking at where you are to figure out where you want to go.
KPIs vary from application to application and, if you do not have them identified and well-defined before beginning down the observability path, it is that much harder, he said.
Most tools (observability or otherwise) are capable of collecting hundreds if not thousands of metrics, but not all—not even most, in many circumstances—will be relevant to an organization.
“Instead of having to sift through the cruft to find the valuable data, it is better to start with identifying the valuable data and then figure out how to get there,” Chessman said. “If you don’t identify your KPIs in advance you could end up using the wrong KPIs for the wrong scenarios.”
Johnston added that KPIs, like DevOps, are an iterative process and starting with KPIs helps developers create systems that can meet performance and availability expectations.
“It’s important that DevOps teams continuously review their KPIs to allow for regular feedback on successes and failures,” he said.
From his perspective, the best place to start for maintaining and improving observability is by storing observability definitions, instrumentation, SLOs, thresholds, incident response templates and dashboards as code.
“This allows for rapid improvement via code changes by any team member, whether that’s a site reliability engineer (SRE), developer or platform team,” he said.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Golang goes from zero to hero, will Broadcom buy VMware? And limitless vacation is still a Thing. (more…)
At its swampUP event, JFrog today launched Project Pyrsia, an open source project that uses a blockchain platform and Sigstore Cosign and Notary V2 cryptographic signature software to secure software packages. In addition to JFrog, other contributors to the project include Docker, Inc., DeployHub, Futureway and Oracle.
Stephen Chin, vice president of developer relations for JFrog, said Project Pyrsia will enable organizations to establish a chain of provenance for open source software components stored in a secure network of repositories.
In effect, Project Pyrsia is making use of decentralized Web3 technologies to secure the open source supply chain, noted Chin. That approach to validating the integrity of software components using a blockchain platform will ensure that any software component being employed by developers has not been compromised, he added.
Ultimately, the goal is to contribute Project Pyrsia to the Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation that, as a consortium, is looking to coordinate efforts to better secure open source software. JFrog’s own research efforts identified more than 20 different open source software supply chain attacks, with two of those involving zero-day threats for which there was no immediate software patch available. Cybercriminals are targeting open source projects because any malware that gets included will later show up in any number of downstream applications. Their ultimate goal is to activate that malware at a time of their choosing.
Securing open source software became a more urgent issue following the discovery last year of the zero-day Log4Shell vulnerability that impacted Java applications. Many developers routinely reuse open source software, but many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited; the onus for making sure that software is secure falls on the organizations that decide to deploy it. The trouble is, many developers assume that software is more secure than it really is. Initiatives like Project Pyrsia are part of a larger effort to make it simpler for maintainers to secure open source software.
It’s not clear whether security concerns are prompting organizations to review the amount of open source software they consume. Most organizations are more dependent on open source software than they realize, because most packaged applications will include open source components. Whenever a zero-day vulnerability is discovered, organizations can spend months looking for all the instances of an open source component that might be vulnerable.
In theory, increased focus on open source software should lead to greater adoption of DevSecOps best practices that reduce the number of vulnerabilities in production environments. In the meantime, more scrutiny of open source software components is necessary, considering that they are employed by almost every organization.
WhiteSource rechristened itself Mend today and launched a remediation platform that automatically resolves security issues for application developers.
Rami Sass, co-founder and CEO of Mend, said now the company is going beyond just identifying vulnerabilities in open source software using software composition analysis (SCA) tools and is also fixing them. The overall goal is to make it simpler for developers to address security issues without taking time away from writing code or slowing down the rate at which applications are developed, he added.
To further that effort, Mend also announced today it is making available a plug-in for JFrog Artifactory that enables Mend Supply Chain Defender, formerly WhiteSource Diffend, to enable detection of malicious open source code. Last year the company acquired Diffend followed by the acquisition of two startup providers of static analysis security testing (SAST) tools.
Collectively, those applications enabled the company to build the Mend Application Security Platform, a software-as-a-service (SaaS) offering that combines SCA and SAST tools to create an automated remediation framework that can be applied to both open source and proprietary code residing in a repository.
Mend claimed it added more than 350 customers in the last year to bring its total to more than 1,000 organizations. Most recently, the company raised an additional $75 million in financing to continue investing in a platform specifically designed to address application security issues. In the wake of a series of high-profile security breaches involving software supply chains, Sass noted there is now a much greater appreciation for securing applications and that demand for application security solutions is growing. That demand, in turn, is fueling a wave of consolidation that is, in part, enabled by the convergence of application security tools made available via a SaaS platform, he added.
Historically, much of the focus on application security focused on discovering vulnerabilities that developers are asked to patch. The issue is that developers are being asked to patch the same modules repeatedly. The Mend Application Security Platform keeps track of what modules have been successfully updated to give developers higher confidence in the updates being applied, said Sass.
Those recommendations are not being surfaced using machine learning algorithms but rather by the data analytics capabilities that have been added to the company’s portfolio of tools over time, he noted.
While there may never be such a thing as perfect security it’s apparent that most application security issues can be traced back to relatively common mistakes that developers routinely make. The more those issues are surfaced within a developer workflow, the less dependent organizations will need to be on embedding guardrails within DevSecOps workflows to prevent vulnerabilities from finding their way into production environment. The Mend Application Security Platform doesn’t eliminate the need for those guardrails as much as it reduces the sheer volume of security issues that might otherwise need to be addressed.
It may be a while before these more advanced developer security tools achieve that result, but it’s clear from how quickly advances are being made that such tools should have a material impact on the overall state of application security.