[stonogo]

> On a scale of engineering "hardness" (meaning, we can predict all side affects of action), software engineering is closer to medicine than to, say, civil engineering.

This level of hubris is pretty revolting. Software engineering is easy. Writing secure software is easy. The difference between civil engineering or medicine and software engineering is that practitioners of the former are held responsible for their work, and software engineers are not and never have been.

Nothing will improve until there are consequences for failure. It's that simple.

[TeMPOraL]

It's not hubris. Software really is hard - that's why it looks more like voodoo than respectable engineering discipline. It has too many degrees of freedom; most programmers are only aware of a tiny subspace of states their program can be in.

I agree lack of consequences is a big part of the problem. But this only hints at a solution strategy, it doesn't describe the problem itself. The problem is that software is so internally complex that it's beyond comprehension of a human mind. To ultimately solve it and turn programming into a profession[0], we'd need to rein in the complexity - and that would involve actually developing detailed "industry best practices"[1] and stick to them. This would require seriously dumbing down the whole discipline.

--

[0] - which I'm not sure I want; I like that I can do whatever the fuck I want with my general-purpose computer, and I would hate it if my children couldn't play with a Turing-complete language before they graduate with an engineering degree.

[1] - which we basically don't have now.

[tremon]

Software really is hard - that's why it looks more like voodoo than respectable engineering discipline. It has too many degrees of freedom;

No, sorry, software does not inherently have more degrees of freedom than e.g. building a bridge has. The reason other engineering fields are perceived as "limiting" is exactly because they have standards: they have models about what works and what not, and liability for failing to adhere to those standards.

I would argue that the lack of standards is exactly what makes software engineering look like voodoo -- but it is because of immaturity of the field, it's not an inherent property. Part of the reason software is so complex is exactly because engineers afford themselves too many degrees of freedom.

And I disagree that establishing standards constitutes a dumbing down of the discipline, in fact the opposite: software engineering isn't, exactly because every nitwit can write their own shoddy software and sell it, mostly without repercussions. That lack of accountability is part of what keeps software immature and dumbs down the profession. As an example, compare Microsoft's API documentation with Intel's x86 Reference Manual: one of the two is concise, complete, and has published errata. The other isn't of professional quality.

[nickpsecurity]

I push engineering methods for software. It really is hard for systems of significant complexity. Just a 32-bit adder takes 4 billion tests to know it will always work. The kind of formal methods that can show heap safety took a few decades to develop. They just did an OS kernel and basic app a few years ago. Each project took significant resources for developing the methods then applying them. Many failed where the new methods could handle some things but not others. Hardware is a precautionary tale where it has fewer states plus an automatable logic. They still have errata in CPU's with tons of verification.

So, it's definitely not easy. The people that pull it off are usually quite bright, well paid, have at least one specialist, and are given time to complete the task. The introduction of regulations might make this a baseline with lots of reusable solutions. We'd loose a lot of functionality that's too complex for full verification with slower development and equipment, though. Market would fight that.

[tremon]

Agreed, I never meant to imply that it was easy. I just meant that a "professional" software engineering discipline is neither a pipe dream, nor undesirable.

[estefan]

> Nothing will improve until there are consequences for failure. It's that simple.

Of course it's not that simple. Clearly you've never written much, if any, real software.

You want to make an SSL connection to another web site in your backend. You use a library. If that library is found to contain a vulnerability that allows your site to be used in a DDoS, where do the "consequences for failure" lie? You used a library.

Do you think people will write free libraries if the "consequences" fall back on them? If not, have you even the slightest understanding of how much less secure, less interoperable and more expensive things will be if every developer needs to implement every line themselves to cover their backs? Say goodbye to anyone except MegaCorps being able to write any software.

Where does this end? Would we need to each write our own OSes to cover ourselves against these "consequences", our own languages?

[biofox]

The same could be said for any industry.

Anyone can practise carpentry, but if someone is going to do so professionally and build structures that can cause injury or damage if they fail, then they should be accountable for the consequences. This is why indemnity insurance exists.

In software, a lack of rigour is fine for toy applications, but when livelihoods and safety become involved, we need to be mindful of the consequences and prepared to take responsibility, just like everyone else in society is expected to do.

[estefan]

The problem is identifying potential risks. It's obvious if I build a building it might fall down. It's not obvious if you sell web cams they might be used to take part in massive DDoS attacks.

[varjag]

Well now it is obvious, and honestly it has been so for a while. The reason we have shitty security is not because the risks are unknown.

[nickpsecurity]

Here's some risks:

1. Your system might be hacked if connected to a hostile network. Avoid that by default.

2. If connected, use a VPN and/or deterministic protocols for the connections. Include ability to update these. No insecure protocols listening by default. Sane configuration.

3. Certain languages or tools allow easy code injection. Avoid them where possible.

4. Hackers like to rootkit the firmware, OS, or application to maintain persistence. Use an architecture that prevents that or just boot from ROM w/ signed firmware if you cant.

5. DDOS detection, rate-limiting, and/or shutdown at ISP level. Penalties for customers that let it happen too often like how insurance does with wrecks.

That's not a big list even though it covers quite a lot of hacks. I'm with the other commenter thinking all the unknowns may not be causing our current problems.

[tremon]

You use a library.

On what basis did you choose that library? Did robustness of the software come in to your evaluation? Did you request a sample from the supplier, and performed stress testing on it? Did you check for certifications/audits of the code you were including in your project?

If that library is found to contain a vulnerability that allows your site to be used in a DDoS, where do the "consequences for failure" lie?

With you, unless you have a contract with your supplier stating otherwise.

[Ygg2]

   > On what basis did you choose that library? Did robustness of the software come in to your evaluation? 
   Did you request a sample from the supplier, and performed 
   stress testing on it? 
   Did you check for certifications/audits of the code you were including in your project?

Even if, you did everything on this list, you could still get a library that has a potential bug, because software is just that complex. Microsoft puts millions of dollars into security and it still has regular vulnerabilities discovered.

And even if, you implement rigorous audit of code, that means you can't update, because you have to go through the same audit rigamarole, each time a bug is found. By the time you audit your software, a new vulnerability will probably be discovered.

Not to mention this essentially makes open sources software nonviable.

[nickpsecurity]

There's a finite number of error classes that lead to codd injection that causes our biggest problems. Some languages prevent them by default, some tools prove their absence, some methods react when they happen, and some OS strategies contain the damage. There's also CPU dedigns for each of these. Under regulations, companies can just use stuff like that to vastly simplify their production and maintenance of software with stronger security.

[Ygg2]

I disagree there are finite number of error classes that lead to attackers disrupting your software/hardware. Code injection is just one of many possible ways to gain control of your computer.

[nickpsecurity]

If you have no interpreters & sane defaults in config, then there aren't many ways to take over your computer. They basically always exploited a vulnerability in the applications that let them run code. That either was in privileged one they wanted to be in or was a step toward one. Blocking code injection in apps would knock out vast majority of severe CVE's I've seen that relate to apps.

Far as finite amount, the vulnerabilities coming in fall into similar patterns enough that people are making taxonomies of them.

https://cwe.mitre.org/documents/sources/SevenPerniciousKingd...

[Ygg2]

Writing secure software is far from easy. It's super, super hard. The fact that you are saying this, makes me wonder if you ever attempted to write secure software?

[jmnicolas]

Do you write code ?