[whatupmiked]

"migrating to programming languages that eliminate widespread vulnerabilities."

"Some examples of modern memory safe languages include C#, Rust, Ruby, Java, Go, and Swift."

"Too often, backwards- compatible legacy features are included, and often enabled, in products despite causing risks to product security. Prioritize security over backwards compatibility, empowering security teams to remove insecure features even if it means causing breaking changes."

"While customer input is important, the authoring agencies have observed important cases where customers have been unwilling or unable to adopt improved standards, often network protocols. It is important for the manufacturers to create meaningful incentives for customers to stay current and not allow them to remain vulnerable indefinitely."

---

The fundamental challenge is that by the time a "secure default" has been universally agreed on, and implemented widely in a space, the target moves again. Meanwhile each vendor decides what is "most secure" based on what they have been able to implement. Businesses are left with the integration challenge, and maintenance burden, of operating equipment that changes underneath their feet with each upgrade/update in the name of "being more secure."

Government agencies could reduce the integration and adoption window by providing implementations of the "secure defaults" that were ready-to-use in the recommended programming languages. To do this they would need to be able to incentivize and recruit personnel that were capable of doing this, and adopt methods and practices that could produce such modules in a timely manner. Do governments want to distribute implementations that are usuable by any actor? Can they produce it in a timely manner? Would industry trust the implementation if it was produced by governments?

When "legacy features" are being asked for it is most likely because they have been shown to work, and integrate, well across the business. A new product may be perfectly secure, but is it usable? The last quote alludes to this, customers need to run the business to generate the revenue to afford the security.

[Yoric]

> The fundamental challenge is that by the time a "secure default" has been universally agreed on, and implemented widely in a space, the target moves again.

That is certainly true, but there is also such a thing as "definitely insecure default", which can (and I believe should) be discouraged piecewise.

[RadixDLT]

lol java? mind as well pick PHP

[Yoric]

How so?

[blueflow]

Because PHP is a memory-safe language?

The problem with Java and PHP is not that they are insecure, its that there is barely any barrier for entry and thus much of the existing code is very low quality.

[noirscape]

The problem with Java and PHP is mostly bad stdlib design although in completely different ways (PHP also has some weird footguns about equality but those are avoidable).

PHPs stdlib is of the "stickball" variety - they just started adding to it with no style guide, which has resulted in very inconsistent naming, poor rules and lots of security issues that they for ages had to fix with workarounds since people coded against the security issues as if it was correct implementationwise.

Java suffers from an overly interfaced stdlib; the stdlib pretty much only contains standards on how to do something rather than actual implementations. The result is that the default values in the stdlib are ancient/unsafe and also aren't amended, so you don't break compatibility with older Java APIs.

Basically both have too much low quality code in their stdlib which propagates out into bad library design (since the quality of the stdlib tends to the rest of the ecosystem - see how javascripts absurdly barebones stdlib led to it accruing thousands of microdependencies).

[tialaramex]

PHP has a lot more of C++'s "All the defaults are wrong" disease than Java does, which can matter for security because if there's a security default, in PHP it's probably wrong unless you fixed it.