Live data from Hacker News

Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

cisa.gov

31–33 of 33 posts

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#31
post #27

Earlier quoted context omitted.

How so?

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.

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.

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#32
The only way you can do secure by design/default is if the customer of your service experiences a productivity gain.

For example, if they can deploy infrastructure more efficiently (and securely as a byproduct). Or if they're able to get reliability out of a software library (and security as a byproduct).

You have to find these win-win situations where the developers/clients are not even aware of security improvements.

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#33
post #20
post #19

Earlier quoted context omitted.

All of those OSes are written in C, C++ and sputterings of asm.

The entire point of an OS is to handle low level unsafe stuff so the user doesn't have to. Writing in a lower level language doesn't just make sense, it's straight up necessary. Rust is the only "modern" language that's anywhere near the stability and maturity required, but it's still quite young and rough.

Totally agree that a low level language is necessary, but my point was that memory-unsafe languages are not necessary, which it seems you agree since you mentioned Rust as a candidate.
Post reply on HN