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, a remote/hybrid work special: Bribes to relocate you, Fridays are forgotten, and big tech firms stop building offices. (more…)
Atlassian today outlined its strategy to increase the appeal of the Bitbucket continuous integration/continuous delivery (CI/CD) cloud service among enterprise IT organizations. Atlassian said it plans to focus on four core pillars: Performance, management, extensibility and security and compliance, starting with an update scheduled for the third quarter.
Dan Tao, head of engineering for Bitbucket Cloud and Compass at Atlassian, said the overall goal is to make it simpler to use the Bitbucket Cloud service running on the Amazon Web Services (AWS) cloud at scale as organizations increase the rate at which they build and deploy software.
Atlassian is still supporting the Bitbucket Server and Data Center editions of the platform, but it’s apparent more organizations are shifting software development to the cloud, he noted. Atlassian is now moving to not only simplify migrations to the cloud by, for example, providing a Bitbucket Cloud Migration Assistant tool, but it is also moving to ensure applications can be developed at scale.
Achieving that goal includes making use of a more advanced diff algorithm that is four times faster in larger DevOps environments, he added.
Other planned enhancements include the ability to execute CI/CD workflows via Bitbucket pipelines, the ability to reuse multi-step pipelines across repositories, tighter administration integration with other Atlassian applications, the ability to encrypt data at rest and integration with the Snyk tool for discovering vulnerabilities in software to improve security.
Finally, the Bitbucket Cloud service will also soon support Bitbucket Mesh, a distributed storage capability that is already employed in Bitbucket Data Center.
Overall, Atlassian sees the migration to the cloud as a means to not only make DevOps workflows more accessible to a wider range of organizations, but also give organizations that have already invested in DevOps the opportunity to streamline those processes, said Tao.
Many DevOps teams today maintain complex platforms with custom integrations that they need to maintain and support. Atlassian provides DevOps teams the option to either employ an integrated platform or use connectors it has created as part of the Atlassian Open DevOps framework to make it simpler for teams to use whatever mix of tools they prefer, he added. In either case, the total cost of maintaining a DevOps environment can be significantly reduced, said Tao.
It’s not clear to what degree organizations that have already invested in DevOps are considering replacing their existing CI/CD platforms. However, as the pressure to accelerate the rate at which software is built and deployed steadily increases, the pressure to further automate DevOps workflows also builds. At the same time, DevOps teams are now being asked to integrate security gateways that require additional custom integrations within legacy platforms that they would need to support alongside existing integrations.
At the very least, more organizations than ever are weighing their DevOps options. The issue, of course, is that the total cost of switching out DevOps platforms is not inconsequential given the current dependency on existing workflows.
You have probably heard the acronym secure access service edge (SASE), and it’s hard to ignore its impact on the technology industry. SASE is a cool new way to implement networking in hybrid environments, and the most important thing about it is that it bakes security into the network fabric. In plain English—when you plug in, you are secure by default.
SASE will have a special impact on two fields near and dear to the hearts of DevOps teams:
Let’s understand the anatomy of the SASE beast, and understand how it will affect DevOps in the years to come.
SASE is a cloud service that extends networking and security capabilities to support hybrid organizations’ dynamic, secure access needs.
SASE combines WAN capabilities with network and security functions, such as firewall-as-a-service (FWaaS), zero-trust network access (ZTNA), secure web gateway (SWG) and more.
A SASE platform bundles multiple security capabilities, including SD-WAN and services like SWG, CASB, ZTNA, FaaS and SaaS. This multi-region, multitenant architecture supports a distributed and remote workforce. SASE uses inspection engines located at points of presence (PoPs) near the endpoints rather than in the data center. SASE clients send traffic to the nearest PoP.
The core characteristics of a SASE architecture are:
Using physical and virtual appliances from multiple vendors is highly cumbersome and costly. SASE enables organizations to replace this disparate model with a single, cloud-native solution. Organizations can use SASE to deliver more technologies and services via one provider instead of several. As a result, it eliminates the cost of miscellaneous network appliances and optimizes cloud costs, by reducing the resources and bandwidth needed to operate a cloud environment.
SD-WAN is an integral component of SASE, providing features such as an active-active failover and WAN optimization that improve performance and increase network resilience. SASE solutions are based on the concept of security automation, with a fully managed network security stack that typically includes SWGs, next-generation firewalls (NGFW), next-generation network architecture and intrusion prevention systems (IPS). This model helps protect all edges, achieving better network visibility.
SASE provides a holistic data protection experience that automates multiple DLP processes, including data discovery and data classification of storage locations, data usage and data in transit. It employs various security measures, such as user and device authentication, to enable control over access to data and resources at all times. Additionally, SASE DLP seamlessly rolls out protection policies across the entire network.
The emergence of services like PaaS, SaaS and IaaS has encouraged organizations to allow remote work. The cloud supports distributed workforces and streamlines business processes, but it also exposes companies to network-based threats. Many organizations store sensitive data with third parties accessed online.
The cloud security stack can easily become siloed, with team members unsure of their responsibilities and overlooking critical processes. A siloed stack is more labor-intensive and harder to track because the security team uses multiple security systems. It can also create alert fatigue, making it hard to identify threats.
While employees mostly work in the cloud, security efforts often focus on the data center. SASE shifts the focus to the cloud while ensuring seamless integration between security services.
With SASE, a single provider delivers the entire security stack, ensuring it functions as a unit. For instance, an SWG uses threat intelligence data to block suspicious traffic, sending unidentified files to a sandbox for testing. The security team can manage the entire stack from one intuitive interface.
Most activities occur at the edge—SASE secures the edge using an identity-driven approach. It is also cloud-native, ensuring a seamless experience.
SASE provides the following advantages for adopting DevSecOps.
SASE helps reduce the challenges involved in cross-team collaboration. Essentially, SASE combines network security with WAN optimization. Modern DevOps teams are physically separate but must work together, requiring reliable and secure connections between team members.
The DevOps approach emphasizes time-to-market, so DevOps teams look for ways to accelerate the CI/CD cycle and push releases faster. An important part of the process is reducing the DevOps team’s reliance on the network and security teams. SASE solutions help optimize performance and enhance security, so the DevOps team doesn’t have to wait for the infrastructure team to configure resources. SASE gives DevOps teams the necessary control and operational cadence without compromising security or performance.
SASE can improve the overall network performance by providing integrated failover and load balancing capabilities. DevOps teams must have reliable connectivity and cannot tolerate disruptions when deploying new software or fixing bugs. Fast, reliable application performance is key to the DevOps workflow.
The SASE architecture improves the networking, ensuring the organization’s edge devices, cloud resources, data center and remote users remain connected. The DevOps team doesn’t have to handle the infrastructure because it is self-healing, fully optimized, and secure. The solution automatically switches to another path if a line fails or a path becomes congested.
SASE protects DevOps projects with built-in security features. When implemented properly, it integrates many security technologies into the network stack. The DevOps team doesn’t have to worry about attackers intercepting sensitive information. Every security service shares the same, unified context to increase visibility and fill gaps that are often present in traditional security architectures. SASE mitigates the vulnerabilities exploited by attackers using NGFW, SWG, IPS, MDR and antivirus services in a single architecture.
SASE can secure internal applications and their interactions, reducing the burden on the DevSecOps team. Applications running on a SASE-based SD-WAN benefit from the added protection of zero-trust network access (ZTNA) and software-defined perimeter (SDP). These technologies help ensure that all interactions between applications and endpoints are secure.
Proprietary apps are often too sensitive to expose to the public Internet. SASE secures these applications by obfuscating traffic, securing all entry points with NGFW, and restricting access with zero-trust network architecture. It constantly inspects all internal application traffic for cybersecurity threats.
In this article, I explained the basics of SASE, which packages multiple networking and security solutions into one managed service.
SASE is giving organizations a new level of flexibility and agility with regard to their core infrastructure and is introducing the concept of security-by-design. Instead of fighting hard to “secure all the things,” we are moving nearer to a world where the “grid” our organization operates on is secure by default. This won’t make DevSecOps any less important. But it will allow us to build our applications and services within a secure, controlled hybrid environment.
More than a year after the massive SolarWinds cyberattack, targeted companies continue to feel its ramifications in both reputation and financial cost. Moreover, the global software supply chain remains vulnerable to severe attacks, whether from a hostile nation-state like Russia–now increasingly in the cybersecurity spotlight due to fears of retaliation due to U.S. sanctions–or from any other cybercriminal party.
As long as the world continues to choose fast over secure, nothing is safe. No one knows how many potential backdoors the SolarWinds attack alone created, which could allow the persistent presence of malicious actors on a seemingly infinite number of networks; nor do we know when the next attack will happen with potentially more dire consequences. For example, six months after the discovery of the Log4j vulnerability and its associated patches, we know that networks and products all over the world remain unpatched, vulnerable and exploitable in all sorts of companies both big and small.
This must change. And that change must start from the inside out; meaning programmers, developers and DevOps teams should start building code more securely in the first place. That also means that those who use cloud services, third-party black box software or the services of hub companies, whose networks connect both suppliers and customers, should better understand how code development affects security. This increased focus on the underlying technology itself will not completely prevent attacks, but it will reduce the number of attacks.
There are signs that the industry is moving in this much-needed direction—or that there are at least more discussions about it. The White House recently hosted meetings with technology experts focused on this very topic. And this spring, the SEC announced that it may begin requiring some companies to report cyberattacks within four days and also provide details about their cybersecurity posture. This increased government attention is raising awareness and could also open the door to regulations, or at least universal best practices for coding protocols. But regardless of eventual, still-hypothetical regulation, developers—and cybersecurity professionals at hub companies—should give serious thought to the process they use to securely build their products.
Of course, an oft-recommended solution is to move to open source software (OSS). Although open source code is still vulnerable to attacks, the processes and practices involved in creating OSS code are transparent, which goes a long way toward crippling the ability of bad actors to conceal themselves. But such an approach will never work on a large scale in the private sector as there is no way to prevent programmers from simply copying others’ novel code, leaving no way to protect intellectual property among software developers.
However, there are other steps that could be nearly as effective, including integrating security features and testing into development tools and processes. For example, making gray and black box penetration testing a routine part of the software production process would go a long way in helping find vulnerabilities in the code that outsiders could find and access. Ideally, developers could then also remedy or repair these vulnerabilities. Also, assessing security at every step of the development process could give crucial insights into vulnerabilities before they are discovered in the wild by malicious actors.
Implementing other methods to spot security flaws in code, including in open source code, would also help. Using innovations like code-signing would alert developers if any changes were made to the code before they use it, helping to spot hackers or backdoors before the code is implemented into the product. In addition, developing better source code scanning technology is important for flagging vulnerabilities. Developers should also undergo training focused on building a product with a secure life cycle and implementing security protocols for merging and accessing the product code; this could prevent cyberattacks from occurring as a result of a faulty (or nonexistent) SDLC process—the same way an electrical engineer couldn’t design a building electric plan without formal training and certification and participating in regular continuing education and recertification.
CISOs and IT professionals also have an active role to play. They need to evaluate the security of their products’ underlying code , taking full advantage of the software bill of materials (SBOM), which lists all components of software (and that could soon be required by law) but that is only one side of it. This needs to be coupled with measures like code signing, scanning for flaws and keeping an updated list of components to spot newly-published weaknesses and vulnerabilities in libraries and frameworks. And it is increasingly important to make sure that contracts with software service providers specify they are adhering to secure development practices.
With the world on high alert and the private sector especially vulnerable to state-sponsored cyberattacks, there has never been a better time to focus on building more secure code. This does not mean that all of the other aspects of cybersecurity—including threat intelligence, incident response plans and hiring and retaining talented professionals—will be any less important. But if the code underlying the software can itself become more secure, these attacks could become fewer in number and their damage less far-reaching.
A survey of CEOs and IT professionals involved in application testing finds a significant gap in terms of how acceptable it is to release software that has not been properly tested.
The survey, conducted by the market research firm Censuswide on behalf of Leapwork, a test automation platform provider, polled 480 CEOs in the U.S. and the United Kingdom (UK) from organizations with more than 500 employees and 480 heads of quality assurance, testers, release and delivery managers and site reliability engineers (SREs).
A full 85% of the CEOs in the U.S. and 69% in the UK said it’s acceptable to release software that hasn’t been properly tested, as long as patches are tested and applied later. Less than half of the IT professionals surveyed (49%) agreed. A full 94% of CEOs also said they’re confident the software released is tested regularly.
However, 79% of the IT professionals admitted that as much as 40% of software goes to market without sufficient testing. As a result, 68% of UK and 52% of U.S. IT professionals said their teams spend five to 10 days per year patching software.
The survey also made it clear that everyone involved is well aware of the risks that lack of testing creates. Nearly every CEO (95%) is concerned about losing their job in the wake of a software failure. Slightly more than three-quarters of the IT professionals (76%) surveyed have the same fear.
More than three-quarters of CEOs (77%) also noted that software failures have harmed their company’s reputation in the last five years.
Many organizations today assume that Agile development and DevOps best practices will enable them to apply patches quickly in the event an issue arises. The trouble is, in the absence of sufficient testing many of those organizations are essentially experimenting on end users.
Leapwork CEO Christian Brink Frederiksen said the primary reason so much software is not being properly tested is that most organizations continue to rely on manual testing processes that can’t keep pace with the rate at which applications are now being developed; one major factor is the use of low-code and no-code tools.
Of the IT professionals at organizations that release insufficiently-tested software, a full 40% cited underinvestment in test automation as a factor, with only 43% of respondents using some type of automation. Other reasons cited for the lack of appropriate testing included lack of time (34%) and increased rates of deployment (29%).
Just over a third of CEOs (34%) and about four in 10 testers (42%) whose companies use or develop in-house software that goes to market without being tested also cited a lack of available skilled developers. More than a third of CEOs (34%) also cited underinvestment in testing personnel.
At a time when more organizations than ever are dependent on software to drive digital business transformation initiatives, it’s apparent that an application testing crisis is imminent. The only thing left to be determined is how catastrophic the fallout will be because existing processes don’t scale to meet the challenge.
Deloitte has expanded its cloud observability practice to include the Dynatrace Software Intelligence platform.
Jay McDonald, managing director and co-chair for modern delivery at Deloitte, said the IT services provider will now provide traditional DevOps and observability consulting expertise along with a set of instances of the Dynatrace Software Intelligence Platform that it will manage on behalf of organizations.
Deloitte opted for the Dynatrace platform because it employs a single agent for collecting metrics, logs and traces that are then analyzed by its Davis artificial intelligence (AI) engine to enable observability, said McDonald.
While there is a growing appreciation for observability to enable DevOps teams to identify the root causes of IT issues before they become major problems, deploying an observability platform requires a lot of specialized expertise. Many organizations are opting to rely on third-party organizations such as Deloitte to manage that task within the context of a larger DevOps workflow, said McDonald.
Managing those workflows has become especially challenging for many organizations to deploy and maintain as they move to build and deploy microservices-based applications, he added.
Michael Allen, vice president of worldwide partners for Dynatrace, said there are now already more than 4,000 organizations using the Dynatrace Software Intelligence Platform, a number that will continue to increase as observability platforms are consumed as a service.
It’s not clear at what rate DevOps teams are embracing observability. The concept has always been a core DevOps principle, but, for the most part, more mature DevOps teams have only been able to achieve what amounts to continuous monitoring of pre-defined metrics. Observability platforms promise to surface anomalies indicative of IT issues before they escalate; DevOps teams can then launch queries to better determine their root cause and potential severity.
One of the benefits of the Davis AI engine is that machine learning algorithms surface the root cause of many of those issues without requiring DevOps teams to know exactly how to construct the right query, noted Allen.
However, the biggest challenge many DevOps teams encounter is they lack the skills required to deploy and manage observability platforms. In fact, many of them are now relying on third parties to manage a wide range of DevOps platforms so they can concentrate their efforts on actual workflows. Hiring and retaining DevOps professionals also has become more challenging as the total number of applications being built and deployed expands beyond DevOps teams’ abilities to effectively manage.
One way or another, the days when IT teams determined the root cause of an IT issue by process of elimination are finally coming to an end. DevOps teams are gaining more visibility into their application environments in ways that surface more meaningful actionable intelligence, regardless of who sets and manages the observability platform. The opportunity to employ that intelligence to improve overall application resiliency and drive a wide range of digital business transformation initiatives is well within DevOps teams’ reach.
JFrog this week announced it has integrated its DevOps portfolio with Microsoft Teams to enhance collaboration.
Deep Datta, a senior product marketing manager for JFrog, said JFrog Artifactory repository and the JFrog Xray software composition analysis (SCA) tool have been integrated via a JFrog App for Microsoft Teams tool that is now available.
The goal is to make it simpler for DevOps teams to collaborate with other members of an organization that has standardized on Microsoft Teams for collaboration, said Datta.
In general, as more organizations are realizing how dependent their business is on software, individuals ranging from application owners to cybersecurity professionals are now looking to collaborate with DevOps teams, noted Datta. In fact, in many cases, business process workflows now need to align with DevOps workflows as businesses become more dependent on software, he added.
While many DevOps teams already use a range of collaboration tools, many of those same teams also need to access Microsoft Teams to engage individuals outside of those teams, said Datta.
The emerging challenge is the number of communication channels that DevOps teams now find themselves using. Each new communication channel added doesn’t necessarily supplant existing platforms; it’s not uncommon for DevOps teams to use Microsoft Teams alongside Slack as well as traditional email depending on the type of messaging and collaboration required. In some cases, for better or worse, DevOps teams find themselves required to juggle multiple collaboration platforms over the course of any application development project.
In general, the relationship between DevOps teams and the rest of the business is evolving in the age of digital business transformation. The pace at which applications are delivered and updated now has a material impact on business goals. Organizations are finding they need to align everything from marketing and customer support to financial planning with software development. A delay in one software development project can have a cascading effect that impacts every aspect of the business. The sooner information is shared via a collaboration platform the easier it becomes for the rest of the business to adapt and respond.
Naturally, not every DevOps team is excited about the level of transparency required. Many issues a software development team would previously have handled internally are now exposed to the agenda of the board of directors. Application delivery and update deadlines are influenced more heavily by revenue goals than the available developer expertise. The key to managing all those expectations is to communicate more frequently. However, all that communication can also take time away from building applications. It’s important to isolate development teams from distractions—like a constant barrage of messages shared with multiple lines of business and across multiple communication channels.
Of course, the only thing worse than all those messages is a failure to communicate critical information in a timely fashion. The challenge is to find a way to filter out all the noise and get critical information to the right person at the right time.
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: Matt Hicks is the new Red Hat CEO, visual accessibility is in focus, and Google Cloud rolls out ARM instances. (more…)
Security Compass this week updated its threat modeling platform for developers to make it easier to surface application security issues.
The latest version of SD Elements 2022 adds support for developer-centric threat modeling diagrams, reusable components, more advanced reporting capabilities and 114 more just-in-time training (JITT) modules. In addition, Security Compass has now integrated its platform with the Black Duck software composition analysis (SCA) tool.
Drew Koelemay, director of product management for Security Compass, said the goal is to make it easier for application development and cybersecurity teams to collaborate using a platform that visualizes cybersecurity threats within a DevOps workflow.
That approach to application security is critical because it becomes easier for developers to understand how changes to applications improve the overall cybersecurity posture of complex app environments where there are lots of dependencies, he said.
Once that visualization is achieved it then becomes possible to create reports highlighting the most prevalent threats and weaknesses across that portfolio, Koelemay noted.
In the wake of a series of high-profile application breaches, organizations of all sizes are looking to better secure their software supply chains by implementing DevSecOps best practices. The issue that immediately arises is the cultural divide between application development teams and cybersecurity professionals. The Security Compass platform surfaces developer-centric visualizations of security issues to help bridge the historic divide that exists between those teams, said Koelemay.
For the most part, cybersecurity professionals view development teams’ lack of cybersecurity expertise to be the root cause of many of the issues they encounter. It’s not that a developer deliberately sets out to build and deploy vulnerable applications. By the time the application is reviewed—often just a few days before it’s supposed to be deployed—it’s often too late to do much about most of the vulnerabilities that are discovered. Cybersecurity professionals and application development teams need to meaningfully engage each other much earlier in the application development life cycle.
The simple truth is developers are not likely to reach out first simply because they don’t know what cybersecurity issues to look for in an application environment. Most of the time they are rushing to meet an application delivery deadline, which makes them perceive cybersecurity as a hurdle to overcome rather than an automated process integrated within their workflow. Cybersecurity professionals, therefore, need to find a way to more constructively engage developers. The onus is on cybersecurity teams to insert themselves at the front end of the application development process rather than waiting at the backend for an inevitable issue to arise.
One way or another, application security is going to improve. The only thing yet to be determined is how painful the process will be. Tools that enable DevOps teams to see for themselves what issues are being encountered should go a long way toward reducing both the level of pain being experienced and the amount of time required to resolve the cybersecurity issue at hand.
Scribe Security today unveiled a Scribe Integrity tool that scans software artifacts to make sure they comply with IT organizations’ security policies before they are integrated into an application.
The Scribe Integrity tool authenticates open source and proprietary source code before it is uploaded into a build. It assumes that all artifacts are “guilty” until they can prove their innocence, said Rubi Arbel, CEO of Scribe Security. That approach makes it possible to ensure the integrity of the overall software supply chain is maintained in a way that doesn’t adversely impact the productivity of developers, he added.
In addition, the company launched GitGat, an open source policy-as-code tool based on Open Policy Agent (OPA) agent software that enables DevOps teams to periodically run reports that surface insights into the security posture of code residing in GitHub repositories.
Arbel said that, in time, GitGat’s reach will be extended to add support for additional continuous integration/continuous delivery (CI/CD) platforms.
The first release of Scribe Integrity addresses Node.js code and the npm package manager with support for additional types of code planned.
The Scribe Integrity tool also identifies all dependencies to enable DevOps teams to generate an accurate software bill of materials (SBOM) as each software artifact is included in the application, he noted. That’s critical because it enables developers, IT operations and cybersecurity teams to simultaneously see what artifacts, including containers, make up an application, noted Arbel. In the future, the company plans to make available a Scribe Hub that will make it easier to share insights into those software artifacts, he added.
A series of high-profile security breaches clearly demonstrated cybercriminals’ skill at injecting malware into software artifacts and compromise any application that incorporates that artifact into an application. That malware can then be activated at some later date to potentially compromise any number of downstream applications.
Those incidents resulted in a greater appreciation for DevSecOps best practices to maintain the integrity of software supply chains. The issue that DevOps teams are trying to address is how to build more secure applications without slowing down the rate at which those applications are built and deployed. As such, DevOps teams are adding tools to the application development process that make it easier for developers to scan code before it is included in an application and verify the integrity of any software component that becomes part of a DevOps workflow.
It’s unknown how long it may be before the adoption of DevSecOps best practices has a meaningful impact on application security. However, waiting to focus on security until after an application has been deployed is way too late. Cybercriminals today can discover flaws and misconfigurations in applications in a matter of minutes. As more applications are deployed, developers can find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building applications that are secure from the ground up is clearly required.