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: Linus says next release will support Rust, FBI warns scammers are getting hired in deepfake interviews, and 80% of IBM staff stay at home. (more…)
Spell checkers, grammar checkers and predictive keyboards all help reduce errors in written communication, but in a creative medium where writers need to innovate new expressions, nothing can eliminate all errors. The same is true in the code we write.
Of course, your code is probably perfect but, on average, all code has bugs. Some of those bugs are benign. Some will cause unexpected early termination. A few will cause runaway resource consumption. And some bugs lead to security vulnerabilities that let users do things that are unexpected and sometimes undesirable.
Those security bugs are behavioral vulnerabilities because they depend on how the code behaves when executed. Another type is an intelligence vulnerability, something that’s part of the correct behavior of the code, but which gives away details about how to exploit a system. These are the two main types of code vulnerabilities; both come with risks.
Tl;dr: How the code works and how attackers can leverage what it does to their advantage.
This covers a broad range of problems, but all of them are a result of the behavior of the code leading to undesirable outcomes in specific circumstances. Most of these are unintentional. An unescaped user input sent to a database can lead to a SQL injection vulnerability or an unsanitized string sent to a browser could create a cross-site scripting (XSS) vulnerability. Some behaviors are intended, but have unexpected consequences; the Log4j string substitution behavior that allowed it to output environment variables or read data from external resources was intentional, but the malicious usage we now call Log4Shell was not. In another recent example, a combination of behaviors could be exploited to gain root privileges on Linux desktop computers.
Tl;dr: What the content of the code tells an attacker about the system and how to access it.
In the 1950s, the phone company—there was pretty much just one at the time—began implementing completely automated dialing that didn’t require a human operator at the switching station to connect the call. The details were first published in a technical journal in November 1954 (see pages 1209 and 1309 here), and the information gleaned from that led to the creation of “blue boxes” that used insider knowledge to allow outsiders to control telephone equipment and make free long-distance calls.
That’s hardly the first example of insider knowledge being leveraged for outside advantage, but its role at the heart of computer hacking and the origins of the PC (the ‘hack’ inspired Wozniak and Jobs) is so legendary that it demands recognition here.
The phone system’s intelligence vulnerabilities were published in the company’s technical manuals—manuals that many thought were only for internal use, and nobody realized were available to untrusted readers. Today, though, intelligence vulnerabilities are in our code.
Secrets abound in code, along with the details about which systems those secrets connect to. These secrets were once difficult to manage and putting them in code was the only practical choice. Now we have tools like Hashicorp Vault, as one example, and secure keystores in almost every cloud, but the legacy and security debt of all those secrets in legacy code are a goldmine for attackers like Lapsus$ and others who specifically target code.
There’s a lot hidden under the surface in the two categories outlined here. Each of us can name many types of behavioral vulnerabilities—many more than the different types of intelligence vulnerabilities—but the two classes of vulnerabilities represent relatively equal risk. Recent events have demonstrated how an attacker with inside knowledge gleaned from code—and with passwords and keys taken from it—can move quickly despite firewalls and other access controls.
Identifying secrets and other intelligence risks in code is relatively easy, but few teams do it because detection is the easy part. Integrating detection in developer workflows so they can take action in-context while working on and reviewing code is the most effective way to eliminate creating new security debt. And tools that give developers the information they need to understand the overall picture of intelligence risks in their code, the areas of highest risk—and that point them to actionable issues they can fix immediately to improve their code health—are necessary to help teams mitigate historical risks, ideally by rotating any secrets found.
Tools exist that can automate that process and help teams to eliminate more than half the risk in their code—but the first step is recognizing where that half resides.
The latest version of the GitLab continuous integration/continuous delivery (CI/CD) platform added a range of monitoring and visualization capabilities as part of an effort to embed a full set of observability capabilities in the core platform within the coming year.
As part of that effort, the latest version of GitLab, 15.1, has now added support for all the metrics defined by the DevOps Research and Assessment (DORA) team that is also part of Google.
In total, the 15.1 version of the GitLab platform has more than 30 updates. These include additional security capabilities in the form of support for the security assertion markup language (SAML) Group Sync and the Supply chain Levels for Software Artifacts (SLSA) framework defined by Google.
Finally, GitLab added links to all configuration files and templates included in the CI/CD platform to the pipeline editor to make it easier to manage large and complex pipelines.
Cindy Blake, director of product marketing for GitLab, said the monitoring, observability and security capabilities added to the platform are part of an ongoing effort to eliminate the ‘digital duct tape’ that many DevOps teams currently rely on to extend a CI/CD platform. In fact, as many DevOps teams look to better secure their software supply chains, many are now taking advantage of the moment to replace do-it-yourself (DIY) approaches with an integrated CI/CD platform based on a common codebase, noted Blake.
As part of that effort, Blake said GitLab is building its own dynamic application security testing (DAST) tools that are more tightly integrated with its CI/CD platform.
In general, there is now an expectation that the tools required to secure software supply chains should be made available within a CI/CD platform, but organizations are still working through the processes that will need to be implemented to achieve that goal, added Blake.
It’s not clear to what degree organizations are looking to replace legacy CI/CD platforms as they modernize application development and deployment. In many cases, however, the technical debt associated with maintaining custom integrations across their DevOps environment has become considerable. Many organizations are revisiting their DevOps workflows as part of an effort to increase overall developer productivity. The challenge, of course, is that migrating from one CI/CD platform to another requires considerable time and effort.
In the meantime, the number of organizations embracing DevOps best practices continues to grow. GitLab is betting that as the total size of the CI/CD market continues to expand, most of those organizations will prefer an integrated platform rather than writing and maintaining custom integrations themselves.
Regardless of approach, the ability to monitor and observe workflows is an essential element of any DevOps workflow. There is, of course, no shortage of observability platforms available. It’s not clear whether IT organizations will adopt one of those offerings versus taking advantage of observability and monitoring embedded within a CI/CD platform. One way or another, however, it’s getting easier to discover the root cause of any IT issue.
Relational databases have become the option of choice for organizations wishing to streamline and scale the use, storage and retrieval of data. Many organizations choose AWS Relational Database Service (RDS) to forego the resource-intensive tasks related to database administration including management and continuous oversight. RDS is a fully managed service that simplifies and automates these processes, making it easy to set up, operate and manage relational databases in the cloud—including MySQL, PostgreSQL, MariaDB or Aurora—and their various time-consuming activities. Reducing costs and automating processes makes significant business sense and allows organizations to focus on performance, scalability and cost-effectiveness as data grows.
That said, AWS is not the owner or the party responsible for securing your data—this duty remains in the hands of the organization. As the cloud provider, AWS does offer an impressive suite of security measures for protecting the infrastructure that runs its cloud services, including access controls, database snapshots and encryption. Their policies, however, clearly state that safeguarding data is within the responsibility of the organization and, as the moderator of your environment, you will be accountable for what occurs within it.
The following are the six most common RDS misconfigurations related to security and compliance that DevSecOps teams should be aware of to secure their data stores and organizational assets.
Broken Geo-Trust (aka Data Sovereignty): RDS provides the convenient option to distribute data across various AWS regions. There are various benefits to this data migration including minimizing latency, disaster recovery capabilities and scaling operations. However, the security and governance risks of cross-geo replication may significantly outweigh these benefits. A common misconfiguration includes migrating replicas or storing backups and snapshots in another location. When sensitive data travels and is stored in another geographic location, the organization may be at risk of violating international compliance requirements such as Schrems II (for EU-to-U.S. data transfer). Additionally, data traveling to various locations may not be visible to security teams or managed by DevOps teams—without a continuously updated inventory, data will spread unobstructed and ungoverned.
The screenshot below displays a copy-snapshot operation of a U.S.-based RDS datastore to an EU region.
Inadequate Retention Periods: AWS allows organizations to retain database instances for a specific period of time as configured by the user. A common misconfiguration of this feature is the existence of unmonitored standalone snapshots, short-lived backups and a failure to permanently delete records. Organizations that retain records for a long period of time may be in breach of their GDPR obligations, whereas short-lived backups may jeopardize the organization’s ability to recover critical data in case of data loss or a ransomware attack. Clear guidelines and open communication between DevOps teams and compliance leads is the first step toward a healthy environment.
The screenshot below presents a recommended and comprehensive backup retention period configuration from an RDS datastore creation process.
Exposed Resources (Network Access): Publicly accessible database ports and RDS instances are a lucrative configuration loophole for malicious actors. Common misconfigurations may cause RDS database snapshots to be publicly accessible, thus providing unauthenticated users with privileges to access and abuse it through brute-force attacks, known CVEs and DDoS attacks—thereby exposing sensitive data. This risk will also impact the organization’s ability to comply with international regulatory requirements and should be a high-priority configuration when creating and maintaining such resources.
The screenshot below presents recommended network (public) access and default port configuration from an RDS datastore creation process.
Weak Encryption: Encryption of sensitive data—both at rest and in transit—is a necessary security baseline to ensure the integrity and confidentiality of organizational data and make it inaccessible to unauthorized users. Common encryption misconfigurations may include implementing inadequate encryption for communication channels such as TLSv1.2 (and higher), weak cipher suites or untrusted CA which may lead to a false sense of security. For data at rest, another common misstep is a lack of key rotation or exposure of the encryption key to unauthorized entities.
The screenshot below presents the recommended basic encryption-at-rest configuration to be enforced when creating an RDS datastore.
The screenshot below presents recommended basic encryption-in-transit configuration to be enforced when creating an RDS datastore.
Improper Authentication & Authorization (RBAC): A cornerstone of adequate data security hygiene is ensuring that access is only associated with a unique account based on the principle of least-privilege, using strong identification methods with appropriate justification. With RDS, users may not use IAM accounts, provide over-privileged access and permissions to either the main instance or to backups and refrain from implementing a user-access quarterly review.
The screenshot below presents the recommended authentication configuration to be enforced when creating an RDS datastore.
Incomplete Audits: Visibility cannot be considered a point-in-time activity. Monitoring of access and use of sensitive data is an essential component of tracking organizational assets and will provide crucial information in case of an incident or potential data breach. Incomplete or misplaced audit records including login/logout events, short-lived audits or leakage of sensitive data from RDS to audit logs increases the risk.
The screenshot below presents the recommended audit and log configurations when creating an RDS datastore.
Misconfigurations and single points of failure in cloud environments may be unavoidable for all organizations, especially those operating at scale, due to knowledge gaps, high velocity of data and changes and a lack of visibility as the amount of data increases. While the security baseline may be covered by RDS configurations, these are only the minimum required to protect your environment. DevSecOps teams are encouraged to work closely with their compliance leads to ensure that customer data is secured; leveraging RDS for its benefits is a complex and entirely more substantial responsibility. Organizations must view their data as an inherent part of their internal assets. As its owner, they should create appropriate ecosystems that allow continuous oversight and monitoring of the data, gaps that may arise and, most importantly, the controls in place to secure it.
For a good long while, DevSecOps referred specifically to vendors like Veracode that did static application security scanning, dynamic application security scanning, software composition analysis and some form of runtime monitoring (usually interactive scanning). Then we realized that DevSecOps was potentially a lot more than that and, like DevOps, we drove the word to encompass all things that shift security left.
That’s where we are now. But that leaves the DevSecOps market confusing to a lot of people. I propose we rename the tools that specifically focus on code quality to Development Security—even though that name is not perfect and all-encompassing. It’s a better fit than terms in other spaces, like Password Management, which includes two-factor authentication (2FA), multifactor authentication (MFA) and, increasingly, passwordless and secrets management, none of which actually use passwords for the focus of their functionality.
This way, we can all understand that DevSecOps is the mindset and methodology and Development Security is one piece of implementing DevSecOps.
There are probably people smarter than I am who have come to this (or alternate) conclusions, and I’m happy to run with their solutions, too—this is just an attempt to make it less confusing for those who don’t live and breathe the security and DevOps markets. If a new person says, “I think we need DevSecOps,” they are in for a journey to actually figure out what they meant and if what they need is actually DevSecOps. We should strive to clarify that so, at the beginning of their research, it is clear that DevSecOps is like DevOps—an overarching term for policies, procedures, mindset and products while the tools that can help with DevSecOps, like those that make up the overarching DevOps toolchain, belong to a market segment named X. In my case, I proposed Development Security because it’s a close fit. What we actually call it is irrelevant, as long as new people understand it is a subset of DevSecOps.
While you continue to keep the systems spinning and the organization online, when you research these products, use phrases like, “I’m looking for Development Security tools that fit with a DevOps environment.” Markets are largely named by vendors and pundits but, in the end, all these people want to talk in terms their customer base recognizes. So, if enough of you ask for Development Security, that’s what they’ll all start calling it. Effective immediately, that’s what I’m calling it. It is a distinctive set of functionality that all orgs who do internal development need, so let’s give it a distinctive name. And yeah, drop me a line if you have a better name. I’m tied to making it easier, not to a specific term.
At its HasuraCon ’22 conference, Hasura today announced the early release of a software development kit (SDK) that extends the reach of its GraphQL platform to additional data sources.
In addition, Hasura is making generally available integrations with the GitHub repository, support for OpenTelemetry Traces within the Hasura Cloud Platform and Microsoft SQL event triggers.
Finally, Hasura Cloud can now be deployed on the Google Cloud Platform while the Hasura Cloud Enterprise edition is now available on the Amazon Web Services (AWS) marketplace.
Hasura CEO Tanmai Gopal said that while the company already provides support for widely used data sources such as the Postgres database, there are many data sources that organizations also want to be able to query via GraphQL application programming interfaces (APIs). Organizations want to be able to join data using GraphQL regardless of what repository it resides in, he added.
The open source Hasura engine at the core of the company’s offerings automatically generate a GraphQL schema from a data source. That can then be used to accelerate the development of APIs to make it easier for a wider range of developers to build applications that aggregate data across multiple sources.
That approach eliminates the backend complexity that IT teams encounter when adding GraphQL APIs to an application environment that already has a range of APIs for internal IT teams to support, noted Gopal.
GraphQL was originally created by Facebook, but it’s still not clear to what degree GraphQL APIs will supplant REST APIs. Developers tend to prefer GraphQL APIs because they provide more granular control over what data is accessed. The challenge is the number of backend services that expose GraphQL APIs is still comparatively limited.
It’s not likely IT teams will replace REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. Overall, the number of APIs employed within IT environments is rapidly expanding as more microservices-based applications are deployed. Each microservice generates its own API. Over time, IT teams will find themselves managing a wider variety of types of APIs.
The challenge is that it’s not always clear who within IT organizations will manage those APIs. They are often created by developers and are left to IT operations teams to maintain. It’s not uncommon for IT teams to find themselves managing hundreds, perhaps thousands of APIs.
In addition, many of those organizations are now consuming data via APIs exposed by other organizations. Over time, the level of interdependency between APIs and applications will serve to make application environments much more complex to manage.
In the meantime, DevOps teams will need to extend existing DevOps workflows to both support and secure GraphQL-based APIs. The amount of sensitive data being accessed via those APIs is likely to accelerate the rate at which organizations are adopting DevSecOps best practices. Let’s hope this happens before they wake up to discover GraphQL APIs have already proliferated across the enterprise.
During the first six months of 2021, IoT devices were breached 1.51 billion times, a significant increase from only 639 million breaches observed for the entirety of 2020. This problem can be attributed to the widespread adoption of the internet-of-things (IoT) and the Windows Server Message Block (SMB), and neither can be avoided in the age of remote work.
But while these technologies offer unprecedented levels of data mobility and oversight for many interconnected digital and physical systems in industrial settings, they also make it easier for malicious actors to penetrate the very fabric of our lives if left unsecured.
This makes it all the more important for DevOps teams and developers to prioritize cybersecurity while creating systems for the IoT. It is important to address the inherent flaws in security like easily-breakable usernames and passwords or saving data without protection on remote access servers.
There is a way developers and DevOps professionals can help curb the increasing instances of cybercrime, and it’s called chip-to-cloud IoT. Let’s explore how it is emerging as a viable way to construct a safer, more valuable and more decentralized system for everyone.
It’s best to investigate potential cybersecurity issues that may befall your organization before finding ways to secure your IoT platforms with solutions such as a shift left security approach (meaning security is embedded in the earliest phases of the application development process) or an IoT decentralization approach, as we’ll expand on below.
Some common security concerns include:
It can be challenging to guarantee the safety of IoT systems because of the following security flaws:
Hackers can gain access to the data processed by your IoT system by intercepting unencrypted messages.
Your device might contain sensitive information such as your location, bank account information and medical records. Attackers can access critical information in many other ways, including by exploiting weakly protected communications.
Even if every piece of data is transported to cloud storage, intruders can potentially target cloud-hosted applications. Therefore, the risk of data leaks is not just from the devices themselves but also from the cloud environments to which they are connected. That is why DevOps pros, developers and software engineers must find ways to protect the technology from the start and prevent hackers from breaching the cloud.
A recent survey by Zscaler revealed that smart TVs, set-top boxes and smartwatches are most susceptible to malware attacks.
If attackers successfully infiltrate an IoT system or insert malware, they may be able to change its functionality, acquire personal data and carry out other malicious activities that can endanger device owners and users.
The trouble is that manufacturers struggle to maintain proper software security to keep their devices safe. Security often takes a backseat when these gadgets are built, leaving buyers to deal with the aftermath if they get infected with malware.
There are two ways for organizations to enhance their IoT security.
The first step is ensuring both device manufacturers and software developers adhere to sound security principles. If the value chain is exposed, the solution must be chip-to-cloud.
Second, they must take an in-depth approach to protecting key technology by layering security controls to create an iron-clad IoT infrastructure.
The chip-to-cloud architecture enables the creation of secure, low-energy networks of IoT devices that can communicate directly with cloud hosting platforms. The collective effort to build a cloud-first technology stack has been costly, inefficient and unreliable.
Traditionally, IT professionals have used non-machine-hosted security tools like firewalls to secure IoT devices. Chip-to-cloud architecture aims to fix this underlying flaw.
Onboard security and computational power are two of the most significant shortcomings of IoT devices. In addition to being more powerful and safe than previous models, IoT devices built with chip-to-cloud security are also more energy-efficient.
Here are the features that make the chip-to-cloud technology so effective:
Reliable software design is essential for IoT devices and other internet-connected devices. It keeps hackers from stealing your identification or duplicating your device for their ulterior motives. Chip-to-cloud delivers on all fronts.
These chipset characteristics confer an extra security advantage. Each IoT node is cryptographically unique, making it nearly impossible for a hacker to impersonate it and access the more extensive corporate network to which it is connected. Chip-to-cloud speeds things up by eliminating the need for traffic delays between the logic program and the edge nodes that are ready to take action on the information.
The chip-to-cloud architecture of the internet-of-things is secure by design. New tools are being developed to provide bespoke and older equipment with data mobility capabilities, just like the current IoT.
Nevertheless, chip-to-cloud chipsets are always connected to the cloud. As a result, the availability of assets and the speed of digital communication across nodes, departments and facilities will be significantly improved. Chip-to-cloud IoT is a significant step forward in the evolution of the IoT toward Web3. Experts predict IoT device customers and value producers will benefit more from these design principles than centralized providers.
The traditional approach to IoT is to cover an already-existing cloud of linked devices with third-party firewalls and other security measures. Its equivalent imagery would be a single umbrella covering a family of 12—or at least attempting to do so. The protocols that govern security must be central to decentralization.
Chip-to-cloud IoT is a powerful, uniquely secured chipset that can be installed inside each device, giving it a far greater connection in the IoT chain than the average IoT gadget.
The cloud manager or analytics application receives data from every node in real-time using the chip-to-cloud technology. The process does not add another layer of protection; instead, it reduces the latency and loss of data packets as they travel from one destination to another.
In the wake of recent global events, general cloud technology and chip-to-cloud architecture are receiving huge investments. IoT can supply the data that companies and organizations need to fuel their client engagement portals, machine maintenance platforms and enterprise planning tools.
That said, the internet-of-things will not be entirely safe even with chip-to-cloud technology. Businesses must have a security-focused culture, standards for managing new IT investments and the expertise to pick the best technology partners.
The Web3 transition will likely be coupled with future Web3 innovations such as blockchain to improve its utility and security. Seeing how the world’s genuine value-creators use these new solid tools will be intriguing.
Considering security at the very onset of any IoT project is critical. Maintaining comprehensive cybersecurity in IoT environments is challenging due to the rising frequency of cyberattacks and increasingly complicated system vulnerabilities.
The safety of IoT devices is essential to the operation of many businesses—and even entire economies. Engineers are under increasing pressure to ensure that the rapidly expanding number of interconnected devices is safe. This is why chip-to-cloud technology is poised to become the next big thing in this field. Are you ready to be the change?
Malicious actors are constantly looking for new ways to gain access to sensitive data and corrupt systems. As software supply chain attacks are on the rise, security has become a top priority and a growing area in the regulatory and standards landscape. DevOps teams need to approach security as an ongoing part of the software development cycle by implementing DevSecOps practices at scale to improve the security of their software supply chain and ensure the components of the application code are trustworthy.
At DevOps Connect: DevSecOps Virtual Summit, on July 12, we’ll share exclusive content from our RSAC 2022 event to help DevOps teams integrate security in their process from the start. Internationally recognized DevOps and security leaders will examine the supply chain risk landscape, market trends and practical solutions, and provide strategic insights on emerging regulatory topics.
Attendees will gain valuable insider knowledge, tips and tricks they can share with their team and immediately put into practice to build a modern cybersecurity practice within their company.
The agenda features a mix of DevOps and cybersecurity topics, including:
The speaker lineup features some of the foremost innovators in the DevSecOps community, including:
In addition to the sessions, attendees can visit the virtual exhibit hall to interact with partner sponsors including Sysdig, Sonatype, Check Point Software Technologies, Prisma Cloud, SUSE, Qualys, Traceable AI and more. The expo hall will be open throughout the event, giving attendees the opportunity to chat with the sponsors and download information at any time.
Registered attendees will also receive a link to access the virtual environment on-demand. To see the full agenda and to register for free, please visit the DevOps Connect: DevSecOps Virtual Summit website.
A report published today by automated application security testing platform ShiftLeft found only one in three applications has an attackable vulnerability. The report also found organizations that prioritized their remediation efforts based on the level of actual threat are fixing 76% of those vulnerabilities within two sprints lasting 12 days, on average.
Based on millions of scans performed in the last year using the ShiftLeft platform to identify vulnerabilities, organizations have reduced the number of vulnerabilities they need to address by 97% on a year-over-year basis, the report found.
In addition, the report noted that the average median scan time is only 90 seconds, which helped drive an overall 68% increase in daily scans year-over-year. Overall mean-time-to-remediate (MTTR) has dropped by 37%, the report also found.
ShiftLeft CEO Manish Gupta said given the increased number of vulnerabilities, it’s more critical than ever for organizations to focus their remediation efforts on those that can be exploited within their IT environment. For example, the report found that only 4% of all Log4j instances discovered in the IT environments analyzed were vulnerable. Rather than spending weeks looking for every instance, Gupta said IT teams would be much better off focusing their efforts on the instances that might actually be exploited.
The challenge is that not enough organizations have a way to score vulnerabilities based on the risk they represent to the business, Gupta added.
While there is a lot more focus on adopting DevSecOps best practices in the wake of a series of high-profile breaches of software supply chains, the ShiftLeft report made it clear that presenting developers with a long list of potential vulnerabilities is counterproductive. The bulk of vulnerabilities that are being discovered are not actually attackable, noted Gupta.
That doesn’t mean application security doesn’t need to improve, but it is clear that a lot of time and effort is being wasted, added Gupta.
In theory, at least, as the cultural divide been application development teams and cybersecurity teams continues to narrow, the overall ability to prioritize remediation efforts should improve. The first step toward achieving that goal is making it easier to identify what percentage of the application attack surface is really vulnerable. Otherwise, developers presented with a long list of theoretical vulnerabilities will continue to prioritize developing new features and capabilities versus remediating vulnerabilities.
One way or another, vulnerability remediation issues will soon come to a head. In the wake of an executive order from the Biden administration to improve overall application security within federal IT environments, many organizations will adopt similar policies and processes. Developers, naturally, will inevitably either push back or do an end-run around processes they deem too onerous. Rather than allowing a stalemate to occur, Gupta said savvy DevOps teams will invest more time in identifying the critical vulnerabilities that need to be addressed before cybercriminals exploit them.
The issue, of course, is that cybercriminals are getting more adept at discovering and exploiting those very same vulnerabilities.
The software supply chain is swiftly becoming a widespread attack vector, and securing it is now in the spotlight. Software supply chain attacks have become a given in 2022, reports Darktrace.
SolarWinds, Kaseya and GitLab are just a few examples of organizations that have been vulnerable to attack in recent years. We’ve also witnessed an increasing number of exploits, like Log4j and Log4Shell that have the potential to affect billions of devices. What these instances have in common is they leverage vulnerabilities in open source software and third-party dependencies commonly used in the software delivery process — meaning one corrupt package could have broad encompassing impacts on the tech industry at large.
I recently chatted with Doug Dooley, COO, Data Theorem, about the consequences of today’s intricate software supply chains. “The software supply chain problem is bad, but it’s only going to get worse in the next five years,” he said. According to Dooley, application security requires a continuous context of how the app functions at runtime in a software ecosystem—otherwise, it will continue to miss gaping holes in the big picture.
Most people understand what a traditional product supply chain is—it encompasses all the components involved to bring a product to the end consumer, from raw materials to manufacturing, distribution and retail locations. But, amid the pandemic and recent international conflict, we’ve witnessed how brittle this chain is. If you shut down one of these components, all consumers feel the effect, resulting in everything from gas hikes to baby food shortages. A full 61% of organizations were hit by supply chain attacks in 2021.
In software, the supply chain can be thought of similarly—there are many components involved between a software product and the end consumer. The developer writes code, integrates third-party libraries and frameworks, puts it in source code systems, pushes it to test environments and eventually deploys it to production. And often, DevOps has the view of this whole picture.
“DevOps has become some of the most powerful people in the business,” said Dooley. “They can take a business person’s idea and turn it into reality in the form of an application.”
Third-party exposures can create huge disruptions in this above workflow. This could take the form of insecure libraries, underlying cloud vulnerabilities or API vulnerabilities, says Dooley. “Customers will embed APIs in the software stack—to them, it’s a black box.” There’s also the potential for misconfigured S3 buckets, which continually leak millions of records. More serious application security threats include remote code execution, which can invoke a detrimental loss of control.
So, why the sudden peak in software supply chain-related security incidents? After all, open source software, APIs and third-party vendors have been around for decades. Well, according to Dooley, there are several factors at play here.
For years, the Silicon Valley mantra has been to ‘move fast and break things.’ Take Netflix engineering, for example, which is constantly evolving services and releasing dozens of changes per day. According to Dooley, such rapid application development often means that security is following development rather than preceding it or becoming integrated into the process, à la DevSecOps. This could lead to what he calls an “ambulance chaser moment.”
The attack surface is heightened as the number of third-party suppliers and dependencies increases. The average company has 254 SaaS apps, Productiv data found. Also, on the attacker side, we’re seeing increasing levels of automation and sophistication. “You only have to be right one time when attacking,” said Dooley. “The deck is stacked in an attacker’s favor.”
The software supply chain issue is a complex problem that won’t be solved by any single action. However, Dooley offered several tips for companies to consider as they confront this broad problem:
“The moment you ship a piece of software, you’ve taken on a risk,” said Dooley. But at the same time, if you’re not creating digital interfaces, you’re missing out on massive opportunities.
Reusing code and open source packages have become necessary to maintain agility to help continuously release digital products. “Even if you build everything from scratch, you’re still reusing a lot,” said Dooley. “Without it, you’d never get to market.” While these tools enable unprecedented speed, we can’t overlook the potential vulnerabilities that may lie within the software supply chain.
With its unique window into the software deployment and automation process, the DevOps sphere will undoubtedly have a role to play in protecting this paradigm. “Let’s push for more transparency and disclosure,” said Dooley. “But don’t hang your hat on that to make your program great—if you really care about this problem, you’ll have to do some heavy lifting in the real world.”