U.S. tightens export controls on items used in surveillance of private citizens

Re:U.S. tightens export controls on items used in surveillan... by bbarnett on Wednesday October 20, 2021 @06:01PM (#28937359)

The real problem is, security needs to be inherent to how developers, managers, work. Instead, security is often a bolt on, after thought, or put off until "thing $x is done".

One example, many popular frameworks. How do you audit every single piece of code brought in by, say, laravel? And how do you do it, if developers want to be able to reuse code?

Answer? You cannot. At all. You can't even reliably handle license compliance.

Yet, we use such frameworks, because security is not first, or even last sometimes. It's not part of the process, it's a thing to think about when a dev, a department has free time.

Many companies have a security team, an audit team. What?! You don't get secure by having people look at security after development, and then spend time fighting over fiscal concerns, to get a code re-write.

I think none of this will ever be fixed, until the CTO position becomes like the CFO position. Mandatory requirements, jailtime for CTOs if they breach certain regulations, and the authority for a CTO to tell everyone from board to CEO "no, thing X will be done".

Yet no one wants that, because of cost, and a desire to get to market first.

[ Parent | on HN ]

Re:U.S. tightens export controls on items used in surveillan... by smaddox on Wednesday October 20, 2021 @08:44PM (#28938832)

This is only true in our existing software ecosystem, where no one bothers to prove any of their assumptions hold (if they even realize they're making assumptions). In a software ecosystem designed with provable correctness in mind, open source software would be at least as viable as it is now, while being provably correct with respect to high level specifications which could much more feasibly be audited.

[ Parent | on HN ]

Re:U.S. tightens export controls on items used in surveillan... by brigandish on Thursday October 21, 2021 @12:26AM (#28940253)

I'm in so much agreement, though I would disagree with the last line. I've seen people wave away security concerns because they don't want to be bothered.

Developers waste plenty of time (we're all on here chatting away for one!) but ask someone to even think about security seems to offend them in the way that asking a teenager to clean their bedroom would.

[ Parent | on HN ]

Re:U.S. tightens export controls on items used in surveillan... by lumost on Wednesday October 20, 2021 @08:18PM (#28938618)

As long as the solution demands radically slower development there will be problems. Do you really believe that a team of 5 overworked devs will re-implement all functionality pulled in by laravel and their app without introducing yet more vulnerabilities?

[ Parent | on HN ]

Re:U.S. tightens export controls on items used in surveillan... by bbarnett on Thursday October 21, 2021 @05:11AM (#28942108)

The point of a framework was, historically, a project which implemented secure, shared, many eyes-on code. Proper code reuse.

Now, with 20k node packages pulled in as deps for a couple of 10 line libraries, or with 100s of phars as deps often for 10 line composer sourced libraries, you often have almost no eyes on for that code reuse.

Devs just indiscriminately pull stuff in, don't care if a package is unmaintained, or was written by someone for fun 5 years ago and abandoned.

This model isn't sane code reuse.

At least with code written by an on site dev, one can have code reviews, sign offs, etc.

None of this even touches on things like hostiles taking over packages, either.

I'll put this another way. Do you audit every single non-core package installed from random sites, at each update, and all its dependencies?

Or, do you even audit each package, all deps, to make sure the project is active, and seems to have a competent admin?

Because code reuse logic means lots of eyes, and abandoned stuff, low use stuff doesn't jive with that.

[ Parent | on HN ]