devopsy.kinsta.cloud

Tag: executive order

  • Aqua Security Claims Compliance With Biden’s Executive Order

    Aqua Security Claims Compliance With Biden’s Executive Order

    Aqua Security this week claimed it is the first software supply chain security platform provider to meet the attestation requirements as defined by an executive order issued to federal agencies last year by the Biden administration.

    A supplementary memo issued by the Biden administration required federal agencies to collect compliance attestation letters for all software they use by September 14, 2023. Those attestation letters need to confirm that the software development environments they employ are secure, that sources of code are trusted and that code vulnerabilities have been remediated, provenance for data and code is being tracked using a software bill of materials (SBOM) and that these processes are being consistently maintained.

    Eilon Elhadad, senior director of supply chain security for Aqua Security, said Aqua Security was able to meet those requirements within 100 days of the issuance of that memo. The Aqua Security platform for securing software supply chains is based on a platform it gained with the acquisition late last year of Argon, a provider of a set of tools that provides an agentless approach to integrating with continuous integration/continuous delivery (CI/CD) platforms that maps the development environment. Armed with those insights, it then becomes possible to prioritize and automate the remediation of vulnerabilities based on security best practices and compliance rules, noted Elhadad.

    The Argon platform also includes code-tampering detection technology that performs validity checks to make sure the integrity of the build process has not been compromised.

    Naturally, there’s plenty of time for other security platform providers to comply with the requirements set forth in Biden’s executive order. However, software development teams are also in a race against time. In the wake of a series of high-profile breaches, it’s become apparent how vulnerable software supply chains really are. Cybercriminals have increased their efforts to compromise developer credentials so they can embed malware in software components and activate them downstream if future application incorporate that component, noted Elhadad.

    It’s not clear how closely enterprise IT organizations are tracking the efforts of the U.S. government to secure its software supply chain, but any entity that builds software used by any of those agencies will be impacted. Advocates of DevSecOps best practices within enterprise IT organizations will undoubtedly use the Biden administration’s requirements to define a minimum baseline for securing software supply chains.

    In the meantime, a new front has clearly been opened in the cybersecurity war. The more applications are targeted, the greater the impetus for shifting responsibility further left toward application development teams becomes. The challenge is not just scanning the code being written by developers, but also making sure the software build created by development teams has not been compromised by bad actors that have inserted themselves into the process, noted Elhadad.

    Given the magnitude of the effort required, it’s not likely that every software supply chain will be secured any time soon. However, the responsibility for securing those software supply chains is weighing more heavily on DevOps teams.

  • One Year Out: What Biden’s EO Means for Software Devs

    One Year Out: What Biden’s EO Means for Software Devs

    It has been just over a year since president Biden issued executive order 14028 (EO) to improve the nation’s cybersecurity posture. Despite the Log4j vulnerability and a worldwide increase in ransomware attacks, this EO signaled a major step in improving software security at federal agencies and establishing cybersecurity as a priority for the U.S. government. While the agencies tasked under this EO have made significant gains, it is important for industry to understand just how much progress has been made since its inception and what that progress means to the average producer of software.

    To understand the effects of the EO, it is important to remember that president Biden does not have the authority to order any government agency to purchase specific software, nor does the president have the authority to require any governmental agency to procure specific software. Instead, the EO instructs heads of agencies to perform specific tasks that will ultimately define more stringent cybersecurity requirements to protect government offices. This doesn’t mean the EO solely applies to U.S. government contractors; if your company is anywhere in the software supply chain leading to a U.S. government purchase, then you need to pay attention to the EO and plan accordingly.

    One of the first of those tasks was for the National Institute of Standards and Technology (NIST) to solicit input from the public and private industry surrounding the structure and management of software supply chains. That work resulted in an NIST publication on EO Critical Software in July 2021. That publication helped outline security measures for software use, including applying practices of least privilege, network segmentation and proper configuration. It also helped NIST to frame the Secure Software Development Framework (NIST sp800-218v1.1) (SSDF) published in February, which provides a set of fundamental secure software development practices.

    This guidance, along with the definition of a software bill of materials (SBOM) by NTIA in November and the updated Cyber Security Guidance for Supply Chain Risk Management (NIST sp800-161r1) released in early May now form part of the risk-based framework that OMB instructed agencies to follow.

    What it Means To Be “EO Compliant”

    Before beginning any discussion about EO compliance, it’s important to recognize that until there are contract clauses defined—and those contract clauses are incorporated into contracts—there isn’t anything to comply with. That process is part of the Federal Acquisition Regulation (FAR) and Defense Federal Acquisition Regulation (DFAR) effort, and the proposed clauses haven’t been published yet. Despite this, we do know enough to start preparing for future compliance and creating processes that will allow for EO compliance.

    The first step is to recognize whether your organization is a supplier within a supply chain of a U.S. government agency. In the context of the EO, that would mean any organization who creates, procures or embeds software into a component or assembly that is ultimately bought by a U.S. government agency. This includes open source software, low-code/no-code frameworks and DevSecOps tooling, to name just a few of the scenarios where U.S. government use might not be immediately apparent. 

    With that in mind, any provider of software within a supply chain should be prepared to answer questions about EO compliance if their software can be used in the U.S. government setting. For some, this could mean updating a few processes; for others, it may prompt a much larger set of changes in the development cycle. Those willing to change may be more likely to retain relationships or gain favor with government suppliers.

    How Software Providers Can Be Proactive

    There are three critical steps that can be performed today as part of preparing an organization for future EO compliance requirements. The first thing providers can do is generate a complete SBOM for their software in an NTIA compliance format and be prepared to attest to its accuracy. While it is not yet clear how the U.S. government will expect to receive an SBOM or what attestation format will be required, generating compliant SBOMs is one of the easiest tasks software producers will face as part of a post-EO world.

    Next, providers should baseline existing software development practices with the objective of aligning with the SSDF (NIST sp800-218v1.1). The SSDF defines a set of tasks that NIST views as a minimum requirement to securely create software and manage the software creation process. If the government procurement requirements include an attestation of compliance to the SSDF, then software producers who already know how well-aligned they are to the SSDF will be that much closer to compliance. 

    Lastly, providers must implement controls related to open source governance. While an SBOM helps identify open source use and the SSDF includes tasks related to its use, neither specifically defines how any software producer is expected to govern their use of open source software. Open source software is fundamentally different from commercial software in many ways; the most important differentiator is that it is freely downloadable from the internet. This free access means that creators likely do not know who their consumers are and thus cannot proactively provide updates or security information. Open source governance processes can help to fill that gap.

    Why It is Time to Embrace the EO

    These first steps can help software providers address the initial requirements that have come out of Biden’s EO and those who get a jump on implementation will have a leg up against their competition. Starting now can save providers a major headache in the long run, as federal agencies seek an understanding of how much risk they bear when operating the software you produce. 

    The rapidly changing cybersecurity landscape was a key driver behind Biden’s EO. Threat actors are evolving their tactics to keep pace with improving cybersecurity postures and it is in everyone’s best interest—from the federal government to the private sector—to put an emphasis on security. An important place to start—regardless of where you are in any software supply chain—is by taking the steps necessary to demonstrate that you understand the risks inherent in operating software and are actively working to reduce those risks for your customers.

  • Can Regulatory Mandates Secure Software Development?

    Can Regulatory Mandates Secure Software Development?

    Software companies have a long history of delivering incomplete and insecure products. This happens for a couple of reasons. Fast time-to-market has always been a business priority, taking precedence over security, especially as DevOps has become the norm in software development methodologies. And software, by nature, is easy to update and change, so some defects or oversights could be allowed to slide through with the thought that “We can always fix it later.”

    Unlike car manufacturers that put a premium on including safety features upfront (or face the heavy hand of regulators), software makers have typically emphasized speed to market as a way to stay competitive.

    But the other shoe often drops on that approach in the form of costly recalls, extensive patch programs, cybersecurity breaches, and other issues. The fix-it-later mentality in software has become increasingly challenging in recent years with the emergence of connected/IoT devices that are harder to keep current and have a greater impact. Connected closed-circuit surveillance cameras, for example, are frequently hunted and exploited on the internet to spy on people. Internet of things (IoT) devices operating at dams or nuclear power plants can now be hacked (as seen at the Bowman Avenue Dam in New York, or three utility companies in Ukraine hit by BlackEnergy malware). And, across the board, the cost of data breaches continues to rise.

    A White House executive order (EO) from 2021 is also putting pressure on software manufacturers, DevOps and DevSecOps professionals to improve quality, with a mandate for U.S. federal agencies to enforce secure software development through their contracts and acquisitions as part of efforts to secure the software supply chain. The core difference between this effort versus previous attempts such as FISMA, is the visibility into the software development process.

    The attention being paid to secure software development is a step in the right direction, but ultimately it’s still up to the industry rather than regulatory bodies, to change the mindset toward building secure software from the ground up.

    Technology is Faster Than Mandates

    The EO represents a shift in the landscape, mandating not just secure products, but secure development practices. Although it applies officially to federal civilian agencies and their contractors, federal regulations and other government mandates often become global standards, as has happened with the General Data Protection Regulation (GDPR), the EU’s privacy and security law.

    But regulatory mandates aren’t enough. They often move too slowly to be a real solution, especially in a software development environment that is moving steadily towards more agile, fast-paced environments where continuous integration and continuous delivery (CI/CD) is the norm. The timelines for new regulations typically require a two-year window for implementation; if a company already has an applicable product in use, it could be up to five years before they’re required to be in full compliance, such as in the payment industry. By that time, the key elements of the industry best practices have already changed. Simply put, technology moves too fast for regulatory bodies to keep up.

    What’s more, the regulations themselves could ultimately fall short if they are perceived to have a high cost burden of compliance. This is specifically true if the technology used in the software development life cycle can’t keep pace with the needs of compliance. In support of the EO, the National Institute of Standards and Technology (NIST) has released Draft Special Publication (SP) 800-218, and, as is routine, accepted open public comments. The feedback from industry consortiums in these situations often includes considerations about the costs of implementing new regulations and can sometimes lead to softening of some aspects, arguing, for example, that the new regulations put an unfair burden on small and mid-sized companies. The final set of regulations can sometimes leave the door open for ways to address compliance without addressing the issues that led to the regulation in the first place.

    For example, the California Consumer Privacy Act (CCPA) is widely hailed as the nation’s strictest set of privacy protections, yet it still has its weaknesses. The most commonly cited weakness is that the law makes it extremely difficult for consumers to take advantage of the new regulations when they feel they have been wronged.

    Industry Must Make it Happen

    Ultimately, it is up to software manufacturers and the industry to improve the security of their software. They should adopt best practices to build secure procedures into the design, development, testing and validation of new software, as well as its deployment and use. NIST’s Secure Software Development Framework is one example of guidance, being drawn from recommendations from groups like BSA, OWASP, and SAFECode. Industry groups, such as the International Organization for Standardization (ISO), could adopt standards for development and certification similar to the universally accepted UL standards for electrical products.

    The rising demand for secure development requires a substantial shift in attitudes toward how software is made. A lot of these things can be more easily implemented if organizations invest in the adaptation of new technologies faster.

    The threat landscape has become too sophisticated and pernicious for the problem of insecure software to be ignored. Fix-it-later is no longer a valid option if organizations want to protect their networks and, especially, their data, which has become the lifeblood of operations in every sector. While regulatory mandates help, the job ultimately falls to the software industry itself and its consortium of like-minded people bridging the gap between developers and DevOps teams of competing companies to ultimately deliver what’s best for the consumers.

  • How the Cybersecurity EO Impacts DevOps Teams

    How the Cybersecurity EO Impacts DevOps Teams

    Eric Greenwald, general counsel for Finite State, talks with Mike Vizard about how the executive order for securing software supply chains issued by president Biden will impact DevOps teams. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Mike Vizard: Hey, guys. Thanks for the throw again. We’re here with Eric Greenwald who is the General Counsel for Finite State, which specializes in cybersecurity around embedded systems. Eric, welcome to the show.

    Eric Greenwald: Thanks very much. Very happy to be here.

    Vizard: The Biden administration is going to save us all from ourselves. We’ve got this whole effort around software supply chain going on. NIST is now trying to define what a critical component of a software supply chain exactly is. That has been a mystery to many of us for a long time. So maybe you could sort this out for us a little bit. What exactly do they mean and what are they looking for?

    Greenwald: Sure. Well it’s a little bit complicated because I think the conventional understanding of what is critical software is a potentially very broad and malleable concept. What NIST is trying to do is narrow the focus a little bit mostly so that it can phase the implementation of the executive order. I think if you look at some other efforts at imposing standards for software security or security in general that there’s been a rollout and the standards weren’t necessarily drafted in a way that made sense or was easy or low cost to implement, and so what they’re trying to do is avoid those pitfalls and do a rollout that starts with a narrower scope but then eventually expands I suspect eventually to pretty much the majority of the universe of software products that the government buys.

    Now where is it going to stand when the executive order actually begins implementation? That’s what this initial definition is meant to establish. But if you look through what NIST has put out so far, it’s not 100 percent clear, and I think we’re going to get some additional guidance both from NIST and also the executive direct some other departments and agencies to put out some additional guidance. The NIST definition that they put out back on the 25th of June includes a proposed set of categories of software that would be defined as critical under the executive order, but it’s not a definitive list.

    I believe it’s CISA from DHS that’s charged with putting out a definitive list somewhere down the line in the implementation of the executive order. I can’t remember the exact date. But in another 30 or 60 days we’ll see a definitive list of those categories from CISA.

    Vizard: Well, are they doing this out of their concern for us all or are we going to get in trouble at some point? Is somebody going to call me up as a developer and say, “Hey, you’re not protecting these critical components and you’re about to be fined or something bad is going to happen”? So what’s the stick that goes with the carrot.

    Greenwald: So the first stick that gets wheeled in is by the Office of Management and Budget, that is going to use it to compel the departments and agencies that are buying software from vendors out there in the private market that they can only buy software that meets the definition of critical software if it has passed the technical requirements that will eventually be promulgated under the executive order. So the first line of people potentially getting in trouble are the departments and agencies for failure to actually implement the EO’s requirements. Now indirectly, what’s going to happen is as the departments and agencies attempt to enforce the standards under the executive order is that they will select software vendors based upon whether those vendors are meeting the technical requirements. So there’s this trickle-down effect that again it’s going to go through those vendors that are selling directly to the government, but then it will also impact all the various companies out there that are providing components to those vendors that sell to the government.

    So it’s not just going to impact vendors who sell directly to the government. What’s more, it’s going to go even further beyond that because I think especially if people start to think that the standards promulgated under the EO are sensible, are a good way to actually impose tighter security requirements, you’re going to see them adopted more broadly and made mandatory not just for those companies that are selling to the government. But you might see industry groups adopting them, you might see a lot of companies as they are buying software telling their vendors, “Hey, we want you to meet these requirements that have been promulgated under the EO. They’re not required by law to, but we’re requiring you under our contract to meet them.” And you might even see insurance companies start requiring them as a prerequisite for obtaining cyber insurance coverage.

    Vizard: I’m not a lawyer, but sometimes when I do look at these regulations I do notice there’s a common theme between them, almost to the point where I feel like somebody kind of copy and pasted something from one into the other. Is that how things work? People kind of look at one agency and say, “Well thanks for taking the lead on this,” but then they just implement it into their regulatory framework?

    Greenwald: So the best analog to offer on that is if outside of the cybersecurity realm is environmental standards, particularly auto emissions standards. You look at California that leads the way in auto emission standards that it imposes on automobiles sold in California. You see a lot of other states adopting those standards as the model. Not all states, by any measure. But the interesting thing is that car manufacturers can’t just meet those standards to sell automobiles in California.

    They’re going to meet those standards for all automobiles sold in the United States and probably other parts of the world too. Switching to an analog from the security world, you look at the NIST framework. The NIST framework, all voluntary. Nothing about it is mandatory. It’s also not specific technical requirements. So it’s a rough analog.

    But if you look at what happened with the NIST framework you see all sorts of contracts that require compliance with the NIST framework. You see other industry groups or even – and again, in the insurance industry, a lot of insurance companies want to know before providing you with cybersecurity insurance coverage do you meet the basic requirements or the guidelines promulgated under the NIST framework. So I think to your copy and paste point, I think yes, it definitely does happen. And my first hope is that the technical standards promulgated under the EO will be sensible and actually promote better security. My second hope is that if they do they get adopted beyond just procurement for the federal government.

    Vizard: Do you think that the compliance process can be automated as we go forward or is this going to be a lot of manual reviews of code? We’re all hoping or looking for – compliance-as-code is kind of the buzzword of the day in the DevOps space. Do you think we can code our way through this?

    Greenwald: So I’m going to avoid getting too deep into technical issues because I’m a lawyer first and a technology guy second, but I’m more technology policy than engineering, for example. My feeling is that the only way we’re going to be able to implement the technical requirements under the EO in a manner that is efficient and effective, and not too costly I should add, is by automating the process. I will note that part of the approach that Finite State takes to this is automating those software reviews, the scanning for vulnerabilities and assessments of what is actually in the software because that is – number one, doing it once manually is labor intensive. Under the EO, my expectation is that you’re going to see requirements to do it repeatedly, and I think the ideal is doing it with every update or at least even if the updates have a long periodicity doing it more frequently than the updates.

    Or let me just say this – I think that the companies that are able to run their security checks on their software regularly are going to be at a competitive advantage as they approach procurement officers in the federal government to buy their software. And the same thing I think is going to apply more broadly across the industry, that the more frequently you can do these security scans the greater your competitive advantage. And there’s just no way to do it frequently without automating it.

    Vizard: We talk a lot about DevSecOps in our world these days. I wonder if this is just going to force that issue where I might as well start biting this bullet now because one way or another the government’s going to kind of drive me towards it whether I like it or not, so maybe now’s the time.

    Greenwald: Yes. Absolutely in two things. The first is that the EO specifically calls for the promulgation of technical standards for secure development of software. The second is, to your point, my view, what I advocate for companies that are looking at the EO and saying, “Hm, where’s this going, who is this going to apply to?” that if you sit around and wait for it to become mandatory for your company and/or your products, that you’re going to be way behind the power curve and that these companies that are looking at this need to start developing a plan, an aggressive plan, to develop securer software development ops, to implement a software bill of materials – and again, we’re going to see very soon where the technical standards for the software bill of materials will land.

    So people I think will be able to start jumping on that soon. And third, having transparency about your security measures, whether it’s software development or testing, that are accessible to anybody buying your software or using your software. And just to add a last point on there, that being able to do that on a repeated basis where the test results can be validated is going to be very important for companies who, again, want to maintain a competitive advantage in the marketplace.

    Vizard: And I suspect that just because I wrote my code before the rules were actually implemented won’t be much of a benefit to me because they’ll expect me to go back and fix stuff that’s in production.

    Greenwald: That’s absolutely right. So number one is that for any software that the federal government procures following the date that the EO is promulgated, which was I forgot now, like early May, any software procured after that date forward has to meet the EO’s requirements, again, if it falls under the critical software definition. I’ll say something about that in a moment. But the other is that eventually the EO expects OMB to impose those same requirements on critical software that is legacy, that predates the promulgation of the EO.

    As a reference, quick note on if your product meets the definition of critical software. As I noted initially, the definition is being drawn somewhat narrowly. Frankly, I think it’s fairly broad as put out by NIST just a week ago. But again, it’s the initial phase and the definition, the scope, is going to get broader, and I would expect it to end up being quite broad at the end of the day. What day that is, is hard to say. But a key to note is that in the frequently asked questions in the NIST definition that they issued last Friday, they specifically say if a procurement officer wants to apply the EO’s requirements to something that doesn’t meet the definition of EO critical software, they can go ahead.

    There’s nothing that prohibits them from doing so. And if I’m a procurement officer and I’m thinking, okay, I’m buying software today. I know that eventually it’s going to have to meet the EO’s requirements. Why am I going to buy something where I’m worried about it meeting the EO requirements? I’m going to buy something today that is going to give me no headaches down the road in terms of whether it actually meets those requirements.

    And what’s more, if you’re buying software, you’re looking at 10 different products and three of them meet the EO’s requirements, to me that’s an indication that those products are safer. And so I think that you’re going to see procurement officers for a number of reasons gravitating towards those companies whose products meet the EO’s technical requirements.

    Vizard: Yeah. I guess I’m a little more worried about how granular it might get, because we have all these libraries and microservices that people build and then they deploy, and the definition of how that thing may become critical could change over time and what I thought was inconsequential suddenly is critical.

    Greenwald: Well again, and as I said at the top, to me if you’re trying to establish a conventional definition of what’s critical, it’s really hard to circumscribe that narrowly. Anything that has access to a system that you might consider critical, should be considered a critical component. If you’re thinking about what’s the conventional understanding of critical, yes, it’s enormously broad. Again, NIST is trying to start a little bit more narrow and expand later, but I don’t think anyone can feel confident if they have a product, unless it’s something that where there’s just no argument that it could ever be construed as critical, that they should be looking at the EO requirements and figuring out a way to comply with them – well I was going to say comply with them now – we don’t have the requirements yet.

    The technical requirements haven’t been promulgated. But as we start to see which way the wind is blowing, where these are likely to land, companies should be looking to develop a plan to meet those requirements where we expect them to land. And again, not just those companies that sell software to the federal government. So the granularity of the definition, to me I don’t want to go so far as to say as it’s irrelevant, but I think that software vendors of all stripes, whether it is the obviously most critical component of an operating system or something that’s not so obvious, that they should all be thinking about how they’re going to comply. There’s a separate question about granularity, and that is how granular are the technical requirements themselves?

    That remains to be seen. I don’t have a good sense as to how specific and how technical NIST and the other agencies are going to get. But I have a lot of confidence in NIST because they have very good experts in house and they also have spent a lot of time developing relationships with the private sector, making sure they understand what the private sector needs, what really hurts the private sector – and I should say hurts them unnecessary, because there’s no way we get to a more secure software landscape, whether for the federal government or more broadly, without enduring some pain and some cost. You can’t wish your way into better security.

    Vizard: Cool. What’s your best advice to folks then right now? What should they be thinking about, what should they be doing, and how do I get ready?

    Greenwald: So the first thing I would say is if you don’t already have a software bill of materials for your products, that you should start moving in that direction and quickly. As I said, I think it’s just in another week or so that we’re going to see the standards for an SBOM promulgated. When that happens, it’ll give you a very specific target to go for. But there’s no reason not to start now in moving towards that. So that’s something that I think people can start working on today. I think it’ll be a little farther in the future before we start seeing again the specific technical standards being promulgated.

    But I would be, number one, keeping an eye on what’s happening with the various bits of guidance and rules and regulations that are coming out of the EO implementation process, so tracking it closely. Second, if you’re looking to what you can do right now, start looking at generally accepted practices, for example, for secure software development. Because I strongly suspect that where NIST lands is going to be pretty close to what are generally accepted best or very good practices with respect to secure software development, and the same thing for security testing. So we’re a little early in the process to be able to say do A, B, and C specifically.

    Again, within a week or two we should have a little bit of that specific A, B, or C with respect to the software bill of materials. It’s going to take a little bit longer before we get those technical specifics for software development and testing. But again, I think that we can expect NIST to hue to what are already generally accepted as good or best practices in those arenas.

    Vizard: Alright. Like it or not, secure software is on the way. Eric, thanks for being on the show.

    Greenwald: You bet. Thank you for having me.

    Vizard: Alright. Back to you guys in the studio.

    [End of Audio]

  • Google Proposes SLSA Framework to Secure Software Supply Chains

    Google Proposes SLSA Framework to Secure Software Supply Chains

    Google is proposing organizations adopt a framework for securing the integrity of software artifacts across a software supply chain.

    Kim Lewandowski, a product manager for open source software security at Google, said the Supply Chain Levels for Software Artifacts (SLSA) is based on an internal framework, known as binary authorization for Borg, that the company has been employing now for more than eight years to secure its software. Borg is the name Google attached to the platform for building and deploying applications upon which Kubernetes is based.

    In its current form, SLSA is a set of guidelines that identifies how to attain four different levels of application security. The goal, however, is to create a framework that will automatically generate auditable metadata that can be fed into policy engines to create a SLSA certification.

    The lowest level of SLSA requires that the build process be fully scripted or automated and generates metadata that enables provenance to be created. At the highest level, SLSA requires a two-person review of all changes made during a hermetic, reproducible build process. At the highest SLSA security level, organizations should be able to assure others that their software supply chain has not been compromised, said Lewandowski.

    Google

    In the wake of a recent series of high-profile breaches of software supply chains, the level of scrutiny being applied to how software is constructed has increased significantly. In theory, at least, developers have assumed more responsibility for application security as part of an overall shift left that provided them with more programmatic control over IT environments. As a result, cybercriminals are now focused on compromising either the credentials of developers as part of an effort to insert malware into application as it is developed, or they are trying to exploit vulnerabilities that developers have inadvertently created by programmatically misconfiguring infrastructure.

    DevSecOps best practices are, of course, being adopted to teach developers how to better secure their application environments. The issue is that not enough developers are learning how to secure applications fast enough. The volume of attacks against the software supply chain continues to grow at a rate that is now much faster than organizations can thwart simply by educating developers. In some cases, organizations are once again empowering cybersecurity teams to make sure software supply chains are secure regardless of the potential impact on the rate at which applications are being developed.

    Google is trying to promote adoption of SLSA as a framework for securing both open source and proprietary application code, said Lewandowski. There’s no silver bullet for securing software, but a framework that ultimately automates as many of the security processes as possible within the context of a DevOps workflow would go a long way toward hardening the software supply chain, noted Lewandowski.

    SLSA is being put forward as a response to a cybersecurity executive order issued by President Biden that, among other things, tasks the National Institute for Standards and Technology (NIST), an arm of the U.S. Department of Commerce, to consult with federal agencies, the private sector, academia and other stakeholders in identifying standards, tools, best practices and other guidelines to enhance software supply chain security. Given the level of dependencies that exist across those software supply chains, that executive order, to varying degrees, now applies to almost any entity that builds software for an organization that, on some level, interacts with the Federal government.

  • What Biden’s Cybersecurity EO Means for DevOps Teams

    What Biden’s Cybersecurity EO Means for DevOps Teams

    On May 12, 2021 President Biden issued Executive Order 14028, also known as the Executive Order on Improving the Nation’s Cybersecurity. This EO covers a lot of ground, and like all executive orders, it instructs agencies of the U.S. Federal Government to perform specific actions. What it doesn’t do is appropriate funding or create industry mandates. That’ll come later, once some of the plenary stages of the EO are complete.

    Despite this, I’m confident that EO 14028 could be as impactful to cybersecurity as GDPR was to data privacy. I’m also confident that the EO has the attention of business leaders who are trying to figure out what it means to them and their teams—DevOps professionals. While the EO has no underlying mandate to private businesses or those located outside the U.S., it does outline a reasonable set of cybersecurity best practices that can be reasonably interpreted as a call to action for greater transparency.

    In this article I’m going to use the terms supplier and buyer, but I don’t mean to imply that money needs to change hands; only that there are producers of software (suppliers) and consumers of software (buyers). If there is one supplier and one buyer, the software supply chain has one link. If that supplier is also a buyer, the chain has two links. For most software, there are many suppliers; in these cases, the supply chain isn’t so much a length of links but more of a mesh of interconnected links.

    The 2021 Synopsys OSSRA report showed that the average audited application had over 500 dependencies, so that mesh is quite complex—to the point where the security practices used anywhere in the mesh are often obscure, at best. It’s this obscurity that attackers can exploit, which is why one of the key tenants of the EO is transparency.

    As anyone charged with operating a piece of software knows, the security testing performed by a supplier isn’t really obvious, but, as a buyer, you assume the supplier has done the right things when it comes to security. But how do you know? Do you know where the code originated from? Do you know what security targets were used by the supplier? If an attacker is actively compromising the application, how would you know?

    These are all very good questions that are reflected in the EO, to varying degrees. Those questions also belie the reality that suppliers test software. Suppliers do, of course, test their software, but what testing techniques did they use and how effective are/were their tools? And, more importantly, how can you confirm that the mitigations and fixes applied to address identified defects were effective for your deployment scenario? After all, it’s not like every supplier is going to provide you with full access to their source code.

    This is where things become quite actionable for DevOps teams that have embraced the principles of operational feedback mechanisms. For those needing a bit of a refresher, that’s the part of the DevOps mobius where lessons learned operating software are fed back into the next iteration of the development flow. Let’s look at two pieces of operational feedback that are mentioned in the EO: least privilege and log management.

    Log management features prominently in the EO in part because logs enable an understanding of how an application is operating. If a supplier provides detailed information about the log structure and flows, it then becomes possible to build alerts in log aggregation services and SIEMs as indications of unexpected operation. That’s the proactive model the EO embraces—as opposed to forensic postmortem log analysis following a breach—but this requires the supplier to provide insights into the log data indicating that the system became compromised. Of course, to provide that type of data, the supplier must have tested their system software in a manner that allows such a log template to be created.

    We’ve heard that software should be developed using principles of “least privilege” for years, but if you’ve ever been asked to run an application as root or had a supplier not detail the precise network ports required by the application, you know there is still work to be done there. The EO specifically calls out cybersecurity techniques like multifactor authentication and zero-trust network access as ways to achieve granular control over how applications operate.

    It is, however, the coverage of Software Bill of Materials (SBOM) that could have the greatest impact for DevOps teams. In effect, the EO stated that suppliers need to tell buyers the origin of all code within an application. While the EO doesn’t specify the elements of an appropriate SBOM, it does instruct NIST to publish the minimum elements of an acceptable SBOM within 45 days of the EO. When combined with the sections on how build environments are created and managed and the security transparency elements elsewhere in the EO, it’s clear that the EO intends to raise greater awareness of how software is created, patched and maintained.

    In the end, Executive Order 14028 sets a high bar for cybersecurity in general—one where everyone involved in the creation and operation of software will need to up their game. I’ve said for years that it’s impossible to patch something you don’t know you’re running, and that remains true. What must be added is that you also can’t reliably secure something when you don’t know how well each component was tested. The EO is prompting us all to take a step toward solving that problem.