What exactly do you think this report accomplishes?
It's not legally binding like Congressional legislation or an executive order.
Nobody has been prevented from using memory safe languages prior to the report being published. I'm sure there are plenty of instances where consultants and contractors have been required to use C or C++ because it's written into hundreds of thousands of pages of antiquated government contracts, but this report isn't a magic wand that's going to change those contracts. You have to convince the most stuffy lawyers imaginable to change them, which is an expensive endeavor that no reasonable business is going undertake unless it affects their bottom line, and that only happens after Congress passes a law. And prior to a law, there's going to be an army of lobbyists ready to carve out a waiver system, render any hope of improving software quality moot.
I'm of the opinion it's merely a clarion call for D.C. parasites to invent ever-more creative ways to waste tax dollars. Without clear objective success criterion defined by the government, the problem will persist indefinitely. And if you're a bureaucrat with friends and family making millions consulting on this problem, you're disincentivized to solve anything. Why cut off the hand that feeds you.
I'm eager to hear your thoughts about these undeniable problems.
This is what I mean. I said you had no idea how the government gets things done and you took it to heart, quoting the HN guidelines and everything. The government doesn't need to pass laws to get its way. Think on that for a second - we're taught that changes can only be made by laws, and yet the government is doing something here that involves no law being passed, no regulation issued. A simplistic libertarian who distrusts government might view this as a simple waste of time, but it's actually an effective way to get things done.
Like I tried to tell you, this is jawboning. Here's an example of various elected officials using it against a social media company (https://knightcolumbia.org/blog/jawboned). It really works, which should scare you more.
Next, I'll assume you've read the report [1] in full, every page, like I did. But I'll add relevant excerpts that demonstrate that this isn't about starting some "War on Memory Unsafety" (my words), but rather encouraging the software industry to adopt better practices, at no cost to the taxpayer.
- Building new products and migrating high-impact legacy code to memory safe programming languages can significantly reduce the prevalence of memory safety vulnerabilities throughout the digital ecosystem.xi To be sure, there are no one-size-fits-all solutions in cybersecurity, and using a memory safe programming language cannot eliminate every cybersecurity risk. However, it is a substantial, additional step technology manufacturers can take toward the elimination of broad
categories of software vulnerabilities.
- Formal methods can be incorporated throughout the development process to reduce the prevalence of multiple categories of vulnerabilities. Some emerging technologies are also well-suited to this technique.xxvi As questions arise about the safety or trustworthiness of a new software product, formal methods can accelerate market adoption in ways that traditional software testing methods cannot. They allow for proving the presence of an affirmative requirement, rather than testing for the absence of a negative condition.
Then it talks about the role the CTO, CIO and CISO can play in an organisation to improve cybersecurity readiness.
- The CTOs of software manufacturers and the CIOs of software users are best leveraged to make decisions about the intrinsic quality of the software, and are therefore likely most interested in the first two dimensions of cybersecurity risk. In the first dimension, the software development process, the caliber of the development team plays a crucial role. Teams that are well-trained and experienced, armed with clear requirements and a history of creating robust software with minimal vulnerabilities, foster a higher level of confidence in the software they produce.xxxvi The competence and track record of the development team serve as hallmarks of reliability, suggesting that software crafted under their expertise is more likely to be secure and less prone to vulnerabilities.
- A CTO might make decisions about how to hire for or structure internal
development teams to improve the cybersecurity quality metrics associated with products developed by the organization, and a CIO may make procurement decisions based on their trust in a vendor’s development practices.
- The CISO of an organization is primarily focused on the security of an organization’s information and technology systems. While this individual would be interested in all three dimensions of software cybersecurity risk, they have less direct control over the software being used in their environments. As such, CISOs would likely be most interested in the third dimension: a resilient execution environment. By running the software in a controlled, restricted environment such as a container with limited system privileges, or using control flow integrity to monitor a program at runtime to catch deviations from normal behavior, the potential damage from exploited vulnerabilities can be substantially contained.
So you, unlike the people who never read the report, would know that this report was all about educating firms on ways that they can become more secure. At no point does it talk about what the federal government might or might not do. It doesn't involve any spending, any corruption, any laws, any lobbyists, anything that people scared of Big Government might worry about. Not a single dollar spent.
And already it is having results. A few days later, Google published a report that broadly agrees with everything the White House is saying, and talking about their implementation plan. Especially for the millions of lines of C++ in the most used software among regular people - Android and Chrome. [2]
Virtually everyone wants to improve software and make it more secure. We're approaching it from different angles and it's being confused for disagreement on the topic.
There's a lot of value in having good faith discussion from each perspective so we can mitigate downside risk while enhancing the upside goal. I'm eager to hear your thoughts on the undeniable problems restated in my previous replies.
Google is not a good example -- they're technically competent and were already doing work in Rust. It seems like focusing on small software shops still writing C++89 code would be better thing to focus mental energy on. Are there any examples of those kind of businesses using this WH report to steer their roadmaps or technology directions?
I can explain it to you but I can't understand it for you.
I've tried to show you how jawboning works, but you're still steeped in a mindset where the government "undeniably" coerces through legislation and regulation.
> I'm sure there are plenty of instances where consultants and contractors have been required to use C or C++ because it's written into hundreds of thousands of pages of antiquated government contracts
Could you show some instances of these contracts? That's on you, I can't prove a negative.
You're imagining that there must be legislation requiring C++ and therefore it's impossible to get a change away from C++ by just talking.
> there's going to be an army of lobbyists ready to carve out a waiver system, render any hope of improving software quality moot.
Now you're beginning to understand why they didn't go with a coercive law or regulation. When people are coerced, they demand carve outs. When you ask nicely, like the White House have here, they may consider it. And there's nothing wrong with carve outs per se. For example, thousands of ships/planes and other systems are going to use Sqlite as their database and that's written in C. No sense in demanding a database in Rust because frankly, Sqlite is proven software, deploying on billions of devices in use today. It deserves a carve out.
> Without clear objective success criterion defined by the government, the problem will persist indefinitely.
Why would you think this is the last you're ever hearing of this? This problem would take a decade to solve, at the most optimistic. Why are you demanding a perfect solution on day one? All they've done so far is pointing out ways the industry can do better. Maybe next year they change the procurement criteria for some defence contracts. Maybe the year after that they change the procurement criteria for all government contracts. They can try different things, iterate on them.
They can look at the success of industry initiatives like https://memorysafety.org in a couple of years and see if that's something they should invest in themselves.
> It seems like focusing on small software shops still writing C++89 code would be better thing to focus mental energy on. Are there any examples of those kind of businesses using this WH report to steer their roadmaps or technology directions?
Are you asking if there are some small shops who have responded to this 3 week old report, completely changed the direction of their business and published a report about it? Even if they had, how would I have heard about it? Google's report reached the front page of HN and that's where I saw it, a small company would struggle to reach that kind of exposure.
Your clear distrust of government makes you unable to see that what they've done is a small, effective step in the long march towards improving software security. That's why you set impossible standards for them ("objective success criterion", "proof of small shops adopting it") and then immediately think you're correct when you see they fail to meet those standards. I can't change how you feel about government, so there's not much left to say. If you feel your "undeniable" points haven't been addressed, I'm not going to attempt it again.
It's not legally binding like Congressional legislation or an executive order.
Nobody has been prevented from using memory safe languages prior to the report being published. I'm sure there are plenty of instances where consultants and contractors have been required to use C or C++ because it's written into hundreds of thousands of pages of antiquated government contracts, but this report isn't a magic wand that's going to change those contracts. You have to convince the most stuffy lawyers imaginable to change them, which is an expensive endeavor that no reasonable business is going undertake unless it affects their bottom line, and that only happens after Congress passes a law. And prior to a law, there's going to be an army of lobbyists ready to carve out a waiver system, render any hope of improving software quality moot.
I'm of the opinion it's merely a clarion call for D.C. parasites to invent ever-more creative ways to waste tax dollars. Without clear objective success criterion defined by the government, the problem will persist indefinitely. And if you're a bureaucrat with friends and family making millions consulting on this problem, you're disincentivized to solve anything. Why cut off the hand that feeds you.
I'm eager to hear your thoughts about these undeniable problems.