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.
At its GrafanaCONline event, Grafana Labs today announced an update to the open source Grafana dashboard. The update adds visual query tools to make it easier for IT professionals of any skill level to launch queries against the Prometheus monitoring platform or the company’s Grafana Loki log aggregations framework.
In addition, Grafana said the open source edition of Grafana OnCall, a scheduling and paging application, is now also available as open source software that can be used in on-premises IT environments. Previously, Grafana OnCall was only available as part of the managed Grafana Cloud service.
Archana Kesavan, director of product marketing for Grafana Labs, said version 9.0 of the core Grafana platform makes Prometheus monitoring more accessible. Prometheus is being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). It is most widely used in Kubernetes environments, but can also be used with monolithic applications. The latest version of Grafana adds support for an exemplars overlay for traces and Prometheus sparse histograms.
Other capabilities added with this release include a dashboard preview and title search capability, support for envelope encryption by default, an expanded navigation bar and a revamped heatmap panel that renders more quickly than its predecessor.
‘
Finally, the alert system that Grafana Labs first introduced as an option is now a default setting.
Kesavan said in addition to making it easier to launch queries, the Grafana Labs approach also limits the ability of a poorly constructed query to impact clusters running Prometheus.
In general, the adoption of Prometheus has risen alongside Kubernetes. At least initially, DevOps teams that adopt Kubernetes often employ Prometheus to monitor the platform. Less clear is the degree to which IT teams will continue to rely on Prometheus once cloud-native applications are deployed in a production environment. Many IT teams already have a monitoring platform they employ that they choose to extend to Kubernetes environments. Conversely, however, some organizations are opting to replace legacy tools with the Prometheus monitoring platform to monitor both Kubernetes environments and legacy monolithic applications.
At the very least, Prometheus has established a de facto standard for collecting monitoring data from Kubernetes environments that can be queried by a wide variety of tools.
One way or another there will soon be fleets of Kubernetes clusters deployed across the extended enterprise that will need to be monitored. DevOps teams will naturally need to decide for themselves how best to monitor those clusters and, ultimately, observe them in a way that enables queries to be launched and issues surfaced before they become a major problem.
In the meantime, DevOps teams might want to consider consolidating many of the monitoring tools they use today as part of an effort to streamline operations. Rather than having to correlate events across a dozen tools to determine the root cause of an issue, the goal should be to have enough tools to ensure verification without spending hours sorting through conflicting reports.
AppSmith has added support for Git repositories to an open source framework for building custom applications using a low-code platform based on the JavaScript programming language.
Rishabh Kaul, head of marketing for AppSmith, said the Git support will make it simpler for developers to manage version control as they iteratively build applications using a set of graphical widgets provided by AppSmith.
AppSmith is used primarily by developers to build internal applications that automate a specific task or workflow. Support for Git makes it possible for multiple developers to more easily collaborate as they add work to a Git branch and make requests within the context of a continuous integration/continuous delivery (CI/CD) pipeline.
That also makes it simpler to test applications and roll back to a previous version in the event something should go wrong, said Kaul.
The Community Edition of AppSmith will make it possible to connect to unlimited public repositories and up to three private ones before requiring developers to upgrade.
In recent years, use of low-code tools has increased dramatically as organizations embrace tools that enable them to build applications faster. Not every application requires developers to employ tools for working with procedural code. There are typically hundreds of use cases where an organization could build and deploy an application that would eliminate the need for an internal team to license yet another packaged application.
In general, AppSmith and other open source tool and framework providers are betting that, as the economy continues to shrink, the adoption of these tools will increase as organizations continue to become more sensitive to costs. That approach will allow them to continue to provide applications tailored to automate specific tasks.
The challenge, of course, is that as the number of applications being built and deployed steadily increases, the DevOps workflows that regularly update, secure and maintain those applications become much more challenging.
It’s not clear what percentage of applications are now being built using some type of low-code tool. However, the overall size of organizations’ application portfolio is generally much higher than it was prior to the pandemic. Many of those applications are driving digital business processes intended to make the workforce more efficient at a time when many employees continue to work from home.
Less clear, however, is how many new applications are being built by so-called citizen developers. One way or another, however, it’s becoming easier for end users that have some basic software understanding to build applications. Inevitably, those application development efforts will also need to be integrated within the context of a DevOps workflow.
Regardless of how an individual DevOps team may view low-code tools, they have permanently altered the application development landscape. The issue is no longer whether low-code tools will be used by developers but rather to what extent. In the meantime, DevOps teams would be well advised to review just how extensible their existing pipelines need to become.
At its cdCon 2022 conference today, the Continuous Delivery Foundation shared a State of Continuous Delivery in 2022 report that found nearly half of developers (47%) use either continuous integration or continuous deployment platforms—but only about 20% report using both to automate all application build, testing and deployment.
Overall, only a little less than a quarter (23%) of the 18,585 developers surveyed by SlashData on behalf of the CDF said they are not involved in any DevOps-related activities.
Fatih Degirmenci, general manager for the CDF, said that the relatively low percentage suggested that DevOps workflows are now more widely employed than ever. Monitoring software and infrastructure performance and using continuous integration to automatically build and test code changes remain the most popular DevOps-related activities cited in the survey, at 36% each.
The survey also found that, among large enterprises, the proportion of low performers when it comes to lead time for code changes has dropped from 34% to 24% in the last six months, while the proportion of top performers that need less than one day for code changes has also increased from 13% to 21%.
Larger enterprises are also seeing an increase in developers that report they can restore a service in less than an hour (22%) versus those that still require one week (18%), according to the report.
The survey also suggested there is a strong correlation between the adoption of modern backend technologies such as microservices, containers and Kubernetes and improved lead times for code changes and time to restore. Survey respondents using containers are twice as likely to have lead times of less than one day, while respondents that have adopted Kubernetes are one-third more likely to be top performers.
However, the survey found no impact on deployment frequency. The percentage of top performers capable of deploying code multiple times per day is 11%, the report found. Developers who don’t use these technologies are, in fact, about twice as likely to deploy multiple times per day. Overall, only 53% of developers that work in backend development are using microservices.
Degirmenci said it is clear there is still much work to be done in terms of simplifying DevOps workflows. The average number of technologies that DevOps practitioners use now stands at 4.6 in the first quarter of 2022. The CDF last month launched a CDEvents project to create a vendor-neutral specification for defining a format for sharing event data across multiple services, platforms and systems.
In the meantime, the CDF survey also noted more than a quarter of respondents (26%) now rely on managed continuous integration/continuous delivery (CI/CD) services rather than building and maintaining a DevOps platform themselves.
It’s too early to say how much complexity is driving organizations to rely on managed services, but as the pace at which applications are being developed continues to increase, more organizations are starting to focus on developer productivity. As a result, more than a few organizations are reviewing their existing approach to DevOps and whether it is actually a bottleneck rather than an accelerant for building and deploying applications faster.
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: Verizon fined for allegedly spreading disease, Bolt Financial repeats the mistakes of the past, and the founder of Yandex resigns. (more…)
Contrast Security this week made available a free security tool that enables developers to scan their code using the same core engine used by the cybersecurity team within their organization.
Steven Phillips, vice president of product marketing for Contrast Security, said while there is no shortage of free tools for scanning code these days, the majority are not especially accurate. The scanning engine in CodeSec by Contrast Security is more than 10 times more accurate, Phillips said, because it is optimized to identify true positives versus generating a lot of false negatives, he claimed. He added that CodeSec is not just another freemium offering for developers that is a hobbled version of a commercial offering.
CodeSec also differs from Contrast Security’s existing application security tool because it provides access to a command-line interface (CLI) that makes it easier to integrate within the context of a DevOps workflow. That approach makes it simpler for organizations to shift more responsibility for application security further left toward developers, noted Phillips.
However, shifting responsibility left toward developers is not a panacea, Phillips said. The Contrast Security approach enables more collaboration between development and cybersecurity teams that are using the same scanning engine via a software-as-a-service (SaaS) platform to discover vulnerabilities, he noted.
It’s difficult to determine just how far cybersecurity might shift left, but every vulnerability discovered by an application development team is one less for cybersecurity teams to ask developers to fix in a production environment. The challenge is making it as simple as possible for developers to discover those vulnerabilities.
One way or another, the amount of time and effort being applied to application security has increased sharply in recent months following the disclosure of a series of high-profile breaches. Cybercriminals are now targeting software supply chains as part of an effort to compromise a wide range of downstream applications. Many of the modules that developers routinely reuse are being compromised by surreptitiously inserted malware. The fundamental challenge organizations are trying to address is how to build and deploy more secure applications without slowing down the rate at which they are built.
Naturally, training developers to recognize security issues is a big part of the equation. However, no two developers are ever going to have the same level of cybersecurity expertise. Tools that identify vulnerabilities in ways that developers can act on are critical for advancing the adoption of DevSecOps best practices. Those tools require some level of acceptance among developers because they tend to prefer CLI tools.
In the meantime, organizations will most likely have to scan a wide range of already-deployed applications for vulnerabilities. Applications running both inside and outside the cloud have been routinely deployed with a minimum level of scanning. The truth is that many developers have tended to view cybersecurity policies as an impediment to building and deploying applications. Unfortunately, cybercriminals now appreciate and take full advantage of the opportunity to wreak havoc.
Orca Security has extended its cloud security platform via a command-line interface (CLI) that makes it simpler to integrate with a wide range of DevOps tools.
Rather than relying on agents, the Orca Security platform creates a risk profile using read-only access to block storage accessed via a runtime hosted on Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform. That approach, dubbed SideScanning, eliminates the need for DevOps teams to deploy and maintain agent software to ensure cloud security.
The platform then scans both workloads and cloud configuration metadata to build a map of risks that better enables DevOps teams to prioritize cloud security efforts.
Orca Security CEO Avi Shua said the CLI will now make it easier to shift responsibility for cloud security further left toward developers and the DevOps teams that support them by making it easier to scan for vulnerabilities with the context of a larger set of DevSecOps best practices.
Cloud security remains a major challenge because infrastructure is often provisioned by developers that have little to no security expertise. It’s almost inevitable that mistakes will be made. Orca Security is making a case for a tool that enables organizations to identify those security issues without deploying additional agent software across a wide area network.
The challenge, of course, is determining how far left to shift responsibility for application security. Even when alerted to a security issue, many developers may not fully appreciate the severity of that issue, noted Shua. Many developers also assume their cloud service provider is providing a level of security that they actually don’t. It’s the responsibility of the entity deploying the application to secure it and the associated configurations used to deploy it. Integrating a cloud security tool within a DevOps workflow becomes critical because it enables more members of a DevOps team to evaluate potential risk to the business as the application is being built rather than after it’s running in a production environment, he added.
Many existing DevSecOps tools don’t provide enough context; all they do is provide static analysis of the code that’s been deployed, Shua noted. Developers need to have a deeper understanding of which issues represent a level of risk that requires their immediate attention, he said.
There is, of course, more focus than ever on cloud security as more organizations review how their software supply chains are constructed in the wake of a series of high-profile cybersecurity breaches. Many are discovering that the level of security visibility they have into cloud computing environments is limited, at best.
It’s not likely security concerns will slow down the rate at which applications are now being deployed in the cloud. Instead, the challenge is better understanding how to secure those applications using substantially different tools and processes than those used to secure applications within an on-premises IT environment.