That new safe software attestation rule from the Homeland Security Department has become final.
That new safe software attestation rule from the Homeland Security Department has become final. Contractors have to start planning now for when the rule goes into effect this fall. For more on how to ensure compliance, the Federal Drive with Tom Temin spoke with Haynes Boone procurement attorney Dan Ramish.
Interview Transcript:
Dan Ramish Well, Tom, part of the challenge here is that the software that’s covered is very broad. It’s not just prime contractors that are selling software to the government, but it seems pretty clear that this will be required of software producers anywhere in the supply chain. And some of those companies may not even be aware that they’re selling to the federal government. So, it seems as though not all software producers that will need to comply with these requirements appreciate that they are upon them. Now, with the attestation form now hitting the streets in final form.
Tom Temin And here’s a question what about firmware? I mean, if you buy a printer today, it’s a full-blown computer with a hard drive and connectivity, and you can convert documents into texts and email them from a printer. All this kind of jazz. Would that be covered, I wonder?
Dan Ramish Yes. Firmware, operating systems, applications, cloud-based software. It even covers actually products that contain software. So very broad in scope. The only limit is that there’s a time cut off September 14th, 2022, or more recent than that, if the software has been released, or if a major version has been released, the software will be covered. And then there are some exceptions for software developed by federal agencies, or open-source software, or third-party open source and proprietary components that are incorporated. It’s only software end products that need to be subject to the attestation requirements.
Tom Temin All right. And then so this goes into effect precisely when I mean the rules finalized. But I think there’s a little bit of prep time.
Dan Ramish Yeah. So technically there are either 3 or 6 months after the OMB approval of the final common form from CISA, the Cybersecurity and Infrastructure Security Agency. And the exact date they didn’t nail that down when they issued it. As is not uncommon, the form came out on March 11th, but it was dated March 8th. So exactly where you’re measuring from is not totally clear, but it’ll be for critical software producers sometime in June, in early June and then September for all other software producers.
Tom Temin And will this take the form of a FAR clause or a clause in contracts that the government issues?
Dan Ramish So that’s a good question. There is a FAR rulemaking in process. It’s far case 2020 302. And there was an update in, recent publication noting that the CAK chair sent the draft proposed Far rule to OIRA. So, the rule is going to come in short order. I think it probably will be a proposed rule, but that will formally implement this in contracts to contractors, and there will very likely be a flow down requirement.
Tom Temin And a big question, I think, on a lot of contractors’ minds is will this have the implications of False Claims Act violations if your attestation is there, but there’s something wrong with your software or your software is fine, but you didn’t attest properly.
Dan Ramish Yes, it’s going to be very important to accurately, and truthfully attest to the requirements. So, it actually mentions right on the form that providing false or misleading information may be a violation of the Criminal False Statements Act, if that is knowing and willful. There’s also a DOJ Civil Cyber Fraud Initiative that’s been going on since 2021. That’s specifically trying to crack down on government contractors, failing to meet cybersecurity requirements, bringing False Claims Act investigations and enforcement actions.
Tom Temin We were speaking with Dan Ramish, a procurement attorney with Haynes Boone. And notwithstanding false claims, there might be other penalties in here, which we’ll get to. But has anyone thought about the question of if you attest to the safety of your software and can prove that to your best knowledge, the attestation was accurate and somebody hacks the software anyway, what happens?
Dan Ramish Well, so there is a knowledge component to a false Claims Act action. So, there’s also the possibility of liability for deliberate ignorance or reckless disregard of the truthfulness of the information. But if you’re complying in good faith, you know, the Shoot case last year made clear that there’s a subjective intent component here. If you’re doing your best, and if you’re able to document that you intended to comply with the requirements, then there at least won’t be an issue with fraud. If in fact there is a breach, notwithstanding your efforts to comply.
Tom Temin All right. And tell us about something else you pointed out the Justice Department’s Civil Cyber Fraud Initiative that’s been going on for several years now. It’s kind of behind all this that could come and bite you.
Dan Ramish Yes. So, DOJ has been paying close attention. And of course, CMMC has been getting a lot of attention in this regard. And whenever there’s a self-attestation requirement, there’s heightened risk for the contractor because they’re doing the assessment themselves that they’re complying. So, DOJ is particularly concerned, of course, because of the national security implications for the government if its software isn’t secure or if other cybersecurity requirements aren’t met. That’s the ultimate driver here. There was an executive order issued back in 2021 improving the nation’s cybersecurity. And the federal government’s concern is they need to be able to keep their own systems secure. And to do that, the software that’s being provided that they’re using needs to be free from vulnerabilities. And there are concerns about knowing where all of the different code comes from. And so, the Civil Cyber Fraud Initiative is certainly one tool that is likely to come into play to ensure that contractors are attesting accurately to meeting the security requirements.
Tom Temin And I guess that could be rough play if things go wrong for you. And you also note that in the rule, there are alternatives to attestation for some companies. What are those?
Dan Ramish That’s right. So, if a software producer is going to comply but can’t yet comply with the attestation requirements, maybe they’re not meeting all of the required security practices. They can draft a plan of action and milestones, which is basically a corrective action type document that identifies the practices they can’t attest to and documents the measures they have in place to mitigate the risks. And then they submit that to the agency or agencies that are using their software. And if the agency’s satisfied with the POAM, then they could continue to use the software. But they have to request either an extension of the deadline from OMB or a waiver in order to be able to do that. And OMB is going to be monitoring the agency’s use of POAMs and acceptance of POAMs beginning in June of this year. They’re going to collect data and make sure that software producers aren’t kind of abusing this, and agencies aren’t abusing the POAM mechanism and are making progress, at least toward meeting all of the requirements.
Tom Temin And it looks as if CISA did loosen the final rule a little bit versus how they proposed it, probably based on industry comments, but you found that it looks a little easier than it might have when it first proposed.
Dan Ramish Yes, they did clarify the scope of attestation a little bit to be a little bit more fair to contractors. So, the contractors are only attesting to the things that are actually within their control. And so, one notable area on that is third party components. And the final form adds language that says that software producers are only required to attest that they follow the secure software development practices for the code that they developed. And there’s a specific carve out. So, they’re not attesting to third party producers of components following the practices. Now, they do have to follow their own precautions for incorporating third party components to mitigate the risk, maintaining trusted source code supply chains using automated tools or other practices, and then maintaining provenance for internal code and third-party components to the greatest extent feasible. So, they have to do some of their own homework to make sure that they are doing their best to avoid introducing vulnerabilities through third party components. But they don’t have to attest to those third parties following the same practices that they’re required to attest to. And there’s also a change in who is required to attest, which is helpful to contractors. The previous version of the form said that only the chief executive officer or the chief operating officer of the company was required to attest. And now there’s an option for a designee of the company who’s an employee and authorized to by the company to sign the attestation instead of the CEO.
Tom Temin Yeah. Can you imagine Satya Nadella of Microsoft, you know, being asked 30 times a day, hey, we’ve got another attestation for you or Larry Ellison of Oracle. I don’t think they’re going to be spending too much time personally attesting.
Dan Ramish Right. Well, and there were real concerns there, right. If your CEO is going to have to sign the attestation, even just doing the work to get them up to speed to understand the technical requirements and then the level of documentation you would want to support, that would be much more extensive. If you have someone who’s technically savvy on your team, that gives you a greater level of comfort that they understand what they’re attesting to.
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
Tom Temin is host of the Federal Drive and has been providing insight on federal technology and management issues for more than 30 years.
Follow @tteminWFED