back to article FOSS developer survey: Mostly male, employed... and many don't care about 'soul-withering chore' of security

A new survey of FOSS (Free and Open Source Software) contributors, conducted by the Linux Foundation and academic researchers, reported that 91 per cent of respondents are male, the great majority has full-time paid employment, and that they spend on average under 3 per cent of their time on security issues, with little …

  1. tiggity Silver badge

    A proper security review of teh code

    In addition to automated tools.

    Should also include someone who is not the author - ideally an expert in security flaws.

    Lot's of developers will not even be aware of the potential security issues with some of the code they produce (far too little proper training / education & too much learning on the job / in your spare time)

    1. Doctor Syntax Silver badge

      Re: A proper security review of the code

      That would require that security experts join FOSS projects.

      The survey suggested that half the people working on such projects are actually paid to do so. The employers sponsoring them might usefully consider seconding any such specialists they have on their staff to spend some time doing this. However some such companies may only be contributing to the extent that specific features of the project benefit them and may be reluctant to pay for something that benefits the project as a whole - including other contributors who may be commercial rivals.

      Other projects which can be quite critical to the whole FOSS "ecosystem" have turned out to have very few contributors and generally run on something less than a show-string with no commercial support. That needs some external foundation to step up to support them.

  2. Irony Deficient Silver badge

    Что дѣлать?

    What is to be done? The report noted that bearing in mind their motivations, “it is unlikely that simply offering money to contributors for focusing on security will move the needle a great deal.”

    Perhaps people who aren’t in the majority in this survey (e.g. people in Africa; women; men under 25 or over 44; people without full-time paid employment — some of these categories could overlap) have different motivations, and offering them money might help to move that needle.

    1. Claptrap314 Silver badge

      Re: Что дѣлать?

      An interesting idea, but security really is the hardest part to get right for most code. It's not a chore to fob off on the newbies.

      1. Irony Deficient Silver badge

        Re: Что дѣлать?

        I agree regarding security, but can it be presumed that the 25–44 male majority of the FOSS-contributing respondents in this survey are old hands at security? If full-time paid employment in security can motivate some people, then putting money into training newbies from that motivated cohort might not be a bad investment.

  3. alain williams Silver badge

    Other big 'not do' is good documentation

    Yes: we all hate it, but without it other will find it hard to use what you write. Others cannot see the inside of your head and grasp what, to you, is completely obvious. This is also a security issue: others might get your creation to work, but not having understood some undocumented subtlety leave some door wide open.

    This is not just a problem of FLOSS code.

    Some do have excellent documentation, eg jQuery

    1. Claptrap314 Silver badge

      Re: Other big 'not do' is good documentation

      There is API-level documentation, of which most projects I encounter are quite good or even excellent, and there is explaining what is going on inside the code. I assume that we're discussing the latter.

      The problem is that documentation is a second source of truth, and, as I first heard in the nineties, "documentation is always out of date". In general, if your code needs explanation, the real solution is to simplify it (and/or name variables carefully).

      And that is hard.

      1. Doctor Syntax Silver badge

        Re: Other big 'not do' is good documentation

        Brookes' view was that the manual should be the first thing you start and the last you finish.

      2. LovesTha

        Re: Other big 'not do' is good documentation

        I think the documentation that is most lacking for many projects is the end user guide.

        1. W.S.Gosset Silver badge

          Re: Other big 'not do' is good documentation

          Yes.

          I'll add that there are _*2*_ [categories of] end-users typically ignored.

          1. the end-user of the software's run-time.

          2. the end-user of the software's code AKA the developer-after-you.

          Most doco is just a reference manual.

          An actual Dev's "userguide" for the physical code lets the Dev start faster and harder and deliver much better code in terms of architectural coherence.

          Sadly, it's the category which almost never is written.

    2. Gene Cash Silver badge

      Re: Other big 'not do' is good documentation

      I think one of the factors in Python's success is the incredibly good documentation.

      It's clear with (very important!) lots of simple examples.

      1. Claptrap314 Silver badge

        Re: Other big 'not do' is good documentation

        If you're talking about the python website, I suggest you check the ruby website & report back.

        I consider the python website to be the first demonstration that the term "Pythonista" is well-earned. Not that I've interacted enough with the python community to render judgement, but I found that website to be atrocious. (I found three different pages which, together, appear to explain what you can do with a list. With no way to effectively search the term.)

  4. Rich 2

    Why is lack of security a surprise?

    The general public don't give a dingo's kidney for security - that's why faecesbook and google etc are so profitable, and why Amazon manages to sell internet-based home "security" kit.

    Why would the average software bod care? They should - yes. But in reality, no. I used to run a commercial website based on an open source framework osCommerce. I found out very quickly that most of the people developing with it didn't give a shit about security, either of their web site or (most depressingly) their customers. The problem is not limited to e-commerce of course.

    One problem is that good security is difficult and most people don't know where to start with it, and have little inclination to find out. And if Bill Bloggs develops a program to twiddle some stuff about, as long as it works for him then he's likely happy; it's not his problem if someone picks up his program and gets borked as a result. I think it's more a reflection of the sad state of humanity than poor engineering practice (which it is, of course)

    1. Doctor Syntax Silver badge

      Re: Why is lack of security a surprise?

      I'd go a step further. The average member of the pulic doesn't want security because it would make the product more difficult to use. Security generally gets traded off for something - convenience, performance, cost, whatever. Right up to the time it becomes obvious it shouldn't have been.

      1. Korev Silver badge
        FAIL

        Re: Why is lack of security a surprise?

        Even as an IT Pro security can annoy me - for example my work are introducing 2FA for the VPN, which is much less convenient than just typing my password. I understand fully why they're doing this, but it does seem like a ball ache.

        Me -->

      2. W.S.Gosset Silver badge

        Non-IT examples:

        Seat belts

        Traffic lights

        Immigration/passport checks

        Etc

  5. Pascal Monett Silver badge
    Flame

    'I find security an insufferably boring procedural hindrance.'

    Well maybe a prison sentence would help you focus your attention a bit ?

    1. Joe W Silver badge

      Re: 'I find security an insufferably boring procedural hindrance.'

      Yup. Elsewhere, away from Foss.

      (not me, I'm not a developer, I write code, yes, as an end to means, but I would not call myself a developer. I was involved in FOSS a while ago, working on a community translation project for documentation)

    2. DavCrav

      Re: 'I find security an insufferably boring procedural hindrance.'

      "Well maybe a prison sentence would help you focus your attention a bit ?"

      Erm? You want to throw people in jail for giving away bad code? Does it have to be the person who wrote those lines, or just anyone who contributed? If Linux has a flaw, does Linus get hauled off in the back of a cop car?

  6. Claptrap314 Silver badge

    "Math is hard"

    Around 1980, Matel released a version of Barbie which would "speak" when a string was pulled. On of the phrases that could be played was "math is hard". This caused the now-familiar uproar, and as a male mathematician, pushed me over the edge towards boycotting Barbie for my own daughters.

    But that does not mean that the phrase itself is not absolutely true. Mathematics is hard. Most of the people majoring in mathematics will never enter graduate school, and the majority who do will not pass their prelims. This is not, as a rule, because those students are any lazier than those who succeed. I call myself "brain-damaged in a socially useful fashion" because of just how different I appear to be wired than the rest of the world. For me, mathematics really was pretty easy for everything up to that point except for one of my prelim courses. (Don't hate me--I suck at sports.)

    If you cannot pass your prelims, then, at some important level, you won't be successful producing mathematical proofs.

    And how can you know that the code you just wrote is secure if you cannot produce a mathematical proof that it is secure?

    It's not quite that hopeless. I expect that there are engineering practices which can be put in place that will allow secure code to be produced. Those practices must be developed by mathematicians (they will be called "computer scientists"), and strictly enforced to work, however.

    "Expect." Honestly, I know of a bunch of things to avoid, but I fall back to doing proofs whenever it matters. Because I can.

    1. Norman Nescio Silver badge

      Re: "Math is hard"

      And how can you know that the code you just wrote is secure if you cannot produce a mathematical proof that it is secure?

      It's not quite that hopeless. I expect that there are engineering practices which can be put in place that will allow secure code to be produced. Those practices must be developed by mathematicians (they will be called "computer scientists"), and strictly enforced to work, however.

      I will just address a dangerous and incorrect inference that many will make from your statement: "the code you just wrote is secure if [you can] produce a mathematical proof that it is secure".

      For many will assume that mathematically rigorous code is secure.

      Mathematical correctness is a necessary condition, but not sufficient.

      1) From a mathematical point of view, proven code is demonstrated to follow rigorously from a set of assumptions. The first challenge is making sure that all your assumptions are valid and apply to the 'real' world. This page on the formally proven seL4 microkernel goes into more depth: seL4 - What we prove...what we assume. There is a telling quotation there: "Mathematical proof is proof as long as it talks about formal concepts. It is when assumptions connect to reality where things may still fail. Albert Einstein is quoted as saying 'As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality.'", which leads on to...

      2) While the algorithm may be demonstrated to be secure under the chosen set of assumptions, it is implemented on real world hardware, which is subject to side-channel attack, e.g. timing attacks, power-fuzzing and a panoply of other techniques. AES is a pretty well proven encryption algorithm but difficult to implement in a secure manner in silico ( Cache Based Remote Timing Attack on the AES ). There are decades of work, some of which is either not classified, or now unclassified dealing with working with EAL/Common Criteria and equivalent security requirements and the hardware issues that have to be resolved.

      3) The hardware your code is implemented on can be compromised in subtle ways, even at the gate level (Stealthy dopant-level hardware Trojans: Extended version : April 2014Journal of Cryptographic Engineering 4(1):19-31 : DOI: 10.1007/s13389-013-0068-0 ). Bullet-proof code can be compromised by tissue-paper hardware. If you cannot trust the hardware your code is running on, it makes it difficult to claim your system is secure, even if the code itself is formally proven.

      There are indeed engineering practices that can mitigate many of the known security vulnerabilities. TEMPEST is one such set of practices which may or may not be over the top for most people.

      A formally proven piece of code is only one step on the long path to secure information processing.

      NN

      Addendum

      1a) One person's experience of use of formal verification is here.

      Ray Wang: Formal Verification: The Gap Between Perfect Code and Reality

      tl;dr Formal Verification is hard, and there are plenty of examples of it going wrong.

      That said, from my point of view, formal verification is obviously useful, and is used in many areas (including chip design and cryptocurrency), but has not made inroads into general-purpose computing as yet. And formal verification is only part of the story: it is all well and good showing that the program correctly implements the specification; but humans write the specification, and there is a great deal of room for specifications to be incomplete and/or inaccurate.

      1. jake Silver badge

        Re: "Math is hard"

        It hasn't made it into general purpose computing, and most likely never will, for one very simple reason: Diminishing returns.

        For the most part, we muddle through and the stuff that needs to be secure is pretty much as secure as it needs to be. When we find holes, we plug them. Lather, rinse, repeat.

        Before you poo-poo the above, kindly consider the patchwork of band-aids on top of band-aids that makes up the inherently unsecure and unsecurable Internet itself.

        1. Claptrap314 Silver badge

          Re: "Math is hard"

          DARPANet was not architected for security. That original sin of the internet has created much of the trouble since. It can never excuse bad practice in my code--or yours.

      2. Claptrap314 Silver badge

        Re: "Math is hard"

        I was addressing the one part of the problem which programmers can address--their own code.

        The hard part of applying proofs to the real world is uncovering the assumptions that are being made. That is the critical aspect of a mathematician's training, and the difference between what one will accept as a theorem and what will scooch past someone else. Your comment does a nice job of uncovering what is needed for a complete claim of correctness.

        However, I specifically did not bring in formal checking. Formal tools are always going to lag in capabilities, and, in the hands of people who are not mathematicians, are readily abused.

    2. Boris the Cockroach Silver badge
      Boffin

      Re: "Math is hard"

      Quote:

      "And how can you know that the code you just wrote is secure if you cannot produce a mathematical proof that it is secure?"

      One of the things my lecturer in distributed computing explained to us is that if you are using a real time system with interupts generated by external events(timers/comms/keyboard presses) , then it is mathematically impossible to prove the system.

      The only way to do a proof would be to enforce a single threaded system that relies on internal timers and offers an output when it wants to rather than when the user wants it to. of course systems like that exist, used in very specific situations (usually monitering systems). but would be a pita to use for something like this PC i'm sitting in front of (or a coffee dispensing machine)

      The only thing you can do is to use engineering best practise to try and avoid falling into the obvious security traps (buffer overrun anyone?) but you are still at the mercy of whatever system your application is running on.... eg password needed... tap tap tap enter passy while a keylogger is records everything you do......

      1. Claptrap314 Silver badge

        Re: "Math is hard"

        That depends entirely on what you are trying to prove about it, and what the nature of the system is.

        Given that the definition of a realtime system is that a response will be placed on a bus within X cycles of an interrupt Y being received, I expect he was overstating things.

        However, unless you have an infinite memory which can be addressed in constant time, interrupts WILL be dropped on the floor. I expect what he showed was some variant on this.

        You can prove that supervisor state won't corrupt, or that a stack won't overflow--or even that a system design is in fact realtime. But it will have a limit on how many interrupts per second it can handle.

    3. jake Silver badge

      Re: "Math is hard"

      Barbie didn't say "Math is hard". Barbie said "Math class is tough". There is a big difference between the two statements ... the idiots bitching about it made it sound like they were equivalent, though, so history has substituted the shorter of the two into the collective psyche.

      1. W.S.Gosset Silver badge
        Happy

        Re: "Math is hard"

        And in any case, _both_ statements are flat-out wrong.

        It's "maths", not math.

        Tchoh. Blurry Yanks.

      2. Claptrap314 Silver badge

        Re: "Math is hard"

        Well, as I've defended the latter, it was useful for me to recall that version. :)

        I do believe your history is more accurate.

  7. Claptrap314 Silver badge

    Offense is fun, defense is hard

    I agree with those who suggest we need to address the culture of rewards to increase the focus on security.

    Start with the CS programs, certainly. No, we need to start earlier than that.

    I taught engineering calculus. My students hated me because I gave 0 points if they made a sign error. I pointed out that if they made a sign error on gravity, that their bridges would not be trustworthy. They did not buy it. I asked them how they would feel if their bank made a sign error in their paycheck? They shut up only because they could see that I would not budge.

    My accountant made a sign error this year that would have cost me $6000.

    "Sloppy" mistakes cannot be tolerated in programming, and thus, in our mathematical coursework. But students are conditioned to expect that such errors are acceptable.

    1. Sometimes an Engineer

      Re: Offense is fun, defense is hard

      And I'd be quite annoyed too, because you're teaching them bad practice. You think trying to teach your students to never make mistakes is going to stop them making mistakes? Because that's never going to happen. You show me someone who never makes mistakes and you'll be showing me a liar.

      In real world engineering we accept that mistakes will happen, so we design systems to mitigate and catch those mistakes before they become problems, and have further processes in place to correct problems once found. Say in my field, any engineering drawing will have two different checkers, we'll have design reviews, we'll have prototypes. And after all that when the product is actually made we'll have several rounds of verification testing as well.

      Good software is similar. While obviously you try and get it right first time, you won't. So you write unit tests, you have peer code review, you have offline testing etc. And then at the end you should also have a QA/QC process to check it's all working. Obviously this is all boring stuff but if you want good product this is whats needed, not just relying on your developers/contributors to never make mistakes.

      1. Ken Hagan Gold badge

        Re: Offense is fun, defense is hard

        I think you are mis-representing the OP and, in fact, the OP is trying to encourage students to do (in maths) what you are advocating (in software). To wit...

        So, you've arrived at an answer? Well done! Come back when you've figured out a way to check it.

      2. Claptrap314 Silver badge

        Re: Offense is fun, defense is hard

        I did not say they would fail the class or a test if they made an error. I said that they would get 0 on that problem. The goal is to get the student to be certain that they are following the rules that they were given exactly in order to arrive at their answers.

        These days, I would be tempted to take a bright second-grader and have THEM check the work. There is absolutely no problem in engineering calculus whose correctness requires anything more than attention to detail to check. (That wasn't true 50 years ago, by the way. The dumbing down of calculus tests has been atrocious.)

        Software is MUCH harder to get right. If you turn in calculus homework with errors in it, you should not be allowed to program.

    2. W.S.Gosset Silver badge
      Happy

      Re: Offense is fun, defense is hard

      Slightly OT but related, and a Fun Fact :

      Sign Errors are rife in finance due to its nature. And every financial engineer/structured/complex trader has always to double and triple check their signs all the way through as soon as they step away from vanilla exotics or routine structures.

      The consequences are not just obviously large but $$impactful.

      Amusing low-cost example just in utter vanillas. The custom keyboard for FX Traders (super high volume, super low transaction costs) has custom Buy & Sell keys. In a head-exploding UI failure, these are right next to each other, jammed together.

      It is not uncommon when the market is running hot, for FX Traders watching the trades&prices zooming past to have a bit of a laugh as they see, for example, all to/from one pair of counterparties : BUY usd 50m SELL usd 50m SELL usd 50m.

      They all know what some poor bastard's just done. A sign error. Hit the wrong key, shouted "sh*t!!", hit the correct key twice (to return to 0, then to execute the correct sign). Tap, sh*t!, taptap.

      1. W.S.Gosset Silver badge
        Headmaster

        Re: Offense is fun, defense is hard

        Hey OP/Claptrap31pi, good example for your PhD-level students:

        Dig up Li's classic piece on Copula Correlation. (Top hit on Google/ddg for those 3 words; the original RiskMetrics PDF is the most readable.)

        A/ AWESOME maths. Just... beautiful.

        B/ catastrophically broken by dint of a single error.

        Due to the maths' extraordinary parsimony for numerical application to summarising bundles of probability distributions (eg, pricing baskets of credit default risk), and allowing whole trades to be expressed, and hence managed, as a single number, the financial markets leapt on it en masse. I accidentally made almost an enemy of my best and favourite physics PhD when he brought it in really excited and I read it and laughed at it and said it was magnificent but broken.

        8yrs later it all went bang (the core driver was politicians forcing retail banks to explode mortgage lending for highrisk/broke people, but if not for this maths technique fooling the wholesale boys downstream, Lehman's et al would have been backpedaling hard much much earlier and the fallout would have been "merely" major rather than catastrophic) and a year or two later someone publicly twigged the maths error.

        "Whoops"

        Great example for your students.

        1. Claptrap314 Silver badge

          Re: Offense is fun, defense is hard

          I left academia when I realized that no on wanted to do the hard work of actually learning.

          As a programmer, I'm getting paid to learn, as are the people around me. It makes an amazing difference in attitude.

          I love the example, though.

  8. Paul Johnston
    Meh

    What surprises me is...

    Security comes lower than writing the documentation.

    Just saying!

    1. jake Silver badge

      Re: What surprises me is...

      It's not really all that bad. Documentation takes forever, because it is a constantly changing target. If you don't believe me, try writing it for any ongoing software project, be it FOSS or otherwise.

      Security, however, should be part of the code framework right from the git-go, and as such probably shouldn't take all that much of Joe Average Coder's time ... assuming, of course, that JAC is competent in the language of choice for the project, which is a whole 'nuther kettle o'worms.

      1. Claptrap314 Silver badge

        Re: What surprises me is...

        If only. What I was trying to say politely is that JAC lacks the capacity to produce valid proofs. He therefore cannot be expected to do an adequate security review of anyone's code, let alone his own.

        Tooling can deal with classes of errors. Methodology can deal with more classes of errors. Careful discipline can ensure that methodologies are adhered to. But the unknown unknowns remain.

  9. Gene Cash Silver badge

    It's not just security, but "brittleness" as well

    People can't even bother to validate input, or defend against bad data from databases or other programs.

    Their attitude is "oh why would they give me bad data?!"

    This is not far from "why would people hack my program?"

    1. Claptrap314 Silver badge

      Re: It's not just security, but "brittleness" as well

      It's pretty much the same in my book. They're giving you bad data because they were hacked, after all.

      Unless they got their bad data from you in the first place.

  10. Anonymous Coward
    Facepalm

    And Rust is going to fix all these problems

    Because incompetent, sloppy programmers can't possibly write in Rust.

    Yeah, Right.

    How much money is Microsoft wasting on pushing this crap?

    1. jake Silver badge

      Re: And Rust is going to fix all these problems

      I have discovered that one can write pretty good Fortran in Rust.

      I think I'll stick with C and perl with a smattering of assembler where warranted.

  11. FlamingDeath Silver badge

    Who knew so many coders were Hipsters then

    Ooooh shiny

    Ooooh new fucktionality

    Old code, BORING!!!

    At some stage in your life, you have to evaluate what you’ve created and take a moment to see if it is actually working. Stop piling shit upon shit

    I honestly dont think a distinction between FOSS and propriety needs to be made here, they’re all equally hipster’ish when it comes to coding, focusing more on new fucktionality rather than perfecting the existing fucktionality

  12. A random security guy

    Real examples will prove why security is difficult

    Security is difficult but the main issues are related to people's mindset. Examples:

    1. I discover a WordPress bug. PM punts the already tested dot security only update to after Black Friday. Site gets hacked. Client spends a month digging themselves out of the hole. Cost? Don't ask. We made a lot of money billing them.

    Moral of the story? PM fires the implementation team.

    2. Client believes that encryption of firmware is good enough. Digital signing is only for others. Appealed to the executives to get our contract terminated. One year later Codecov happened. Now they are scrambling to cover up their loss of IP. And yes, they stuck the symmetric keys in source code as no one will be able to figure it out.

    Moral of the story? Managers don't care that they tried to burn the security people. We are expendible.

    3. Vulnerable jQuery. Refused to update since we had not shown them all the ways they could be exploited. I told them that weaponization would take 2 months. Updating with just require testing. Fortunately, the execs stepped in.

    Moral of the story? I should have them for the 2 months to write the exploit.

    4. Password stuck inside JavaScript. Admin password, that is. Checks if user is admin. If true, uses admin as password. Refused to fix the issue as no one would be able to figure it out. They did.

    Moral of the story? Should have gotten that ass fired. Which they did a year later. He now works for PayPal in their senior mgt.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022