4 ms·

While it is true that a threat model is really needed to inform prioritisation of security controls and other mitigations, there are many secure coding techniqu

While it is true that a threat model is really needed to inform prioritisation of security controls and other mitigations, there are many secure coding techniques that developers should be using, but clearly often don't. As a security architect who comes from a dev background, I am acutely aware of the pressures devs are under to ship code. Even so, there are some things you should really try to write securely without a formal threat model. As a professional you should at least be aware of common vulnerabilities in code and not blindly keep creating them, e.g. know your OWASP top ten if you're writing for the web or mobile.

watwut 4y ago
> there are many secure coding techniques that developers should be using, but clearly often don't. I will bite here. Which ones exactly should be used and are not by common developer? > know your OWASP top ten if you're writing for the web or mobile. There is no "my OWASP top ten" and being able to list them helps zero in day to day coding work. The practical knowledge about secure coding does not come from OWASP. It actually typically comes from documentation of frameworks you use, their communication about their libraries and then knowledge about process.
- MattPalmer1086 4y ago
  That's interesting, thanks. I can see how practical techniques will make most sense if they are closer to what you're doing. I'm wondering how to bridge that gap so there is some assurance for the organisation as well as training for the developer.
  - watwut 4y ago
    What it is that you want to teach them in the training? I mean the question genuinely, not as a snark. I am curious about what you (or other security people) see as missing part. I have seen security audit of what we were working on done few times and found it interesting to read. It is good to put that stuff into training materials and repeat it to people. It is actually cool if you can demonstrate attack on their own software (there is always someone who will call your attack theoretical until you demonstrate it). Imo, the best security is the one that does not depends too much on developers remembering to do the right thing all the time. So for example if there is a method that leads to protentional SQL injection or XSS or whatever, prohibit its use and write unit test for it. Basically, static analysis of a code. So then, when someone accidently uses it, the test suite will complain. Hide unsafe things behind internal libraries that force developers do the right thing. Make the right thing easier then the wrong thing. The other good thing are checklists - checklist of ui code, checklist for API, checklist for database, checklist for configuration. In my opinion, if you want assurance about something important, have checking it regular routine part of process and ideally automated. There is always someone who does not know or dont care or is just tired and not focusing. The best compliance is the one that happens automatically as the easiest thing to do.
    - MattPalmer1086 4y ago
      I'm currently working on SDLC security. There's lots of different pieces: peer review, secure code review, threat modelling, training, secure patterns, coding standards, static and dynamic analysis, software composition analysis, build pipeline security, and pen testing! And a bunch of other things to think about. In terms of the developer facing stuff, I'm keen not to repeat the sins of the past where security teams dump a whole load of well-meaning but practically useless stuff on them. As I say, I've been on the other side of the fence. Management and compliance people want assurance that devs are aware of relevant secure coding techniques and pitfalls, but they tend to glom on to big, well known standards, even if half of it isn't useful. I like the idea of finding coding examples relevant to the tech they use, that demonstrates insecure and then secure patterns. For the things that actually make a difference... And then to link the secure coding standards to that as well. Join it up, keep it relevant and practical. Then I just have to demonstrate that this actually meets what the compliance people want to see...
- MattPalmer1086 4y ago
  I hear you on OWASP in fact. I think the earlier iterations of it were more useful to developers. It focused on very specific vulnerabilities and it was a lot more concrete. Now it has morphed into a much more abstract taxonomy of vulnerabilities and covers mobile as well as web. I think security people love this stuff, but it's much less directly useful to a normal dev. It has very good brand recognition though! Even management types have heard of it, which is unusual for a security standard!

watwut 4y ago

> there are many secure coding techniques that developers should be using, but clearly often don't. I will bite here. Which ones exactly should be used and are not by common developer? > know your OWASP top ten if you're writing for the web or mobile. There is no "my OWASP top ten" and being able to list them helps zero in day to day coding work. The practical knowledge about secure coding does not come from OWASP. It actually typically comes from documentation of frameworks you use, their communication about their libraries and then knowledge about process.

MattPalmer1086 4y ago
That's interesting, thanks. I can see how practical techniques will make most sense if they are closer to what you're doing. I'm wondering how to bridge that gap so there is some assurance for the organisation as well as training for the developer.
- watwut 4y ago
  What it is that you want to teach them in the training? I mean the question genuinely, not as a snark. I am curious about what you (or other security people) see as missing part. I have seen security audit of what we were working on done few times and found it interesting to read. It is good to put that stuff into training materials and repeat it to people. It is actually cool if you can demonstrate attack on their own software (there is always someone who will call your attack theoretical until you demonstrate it). Imo, the best security is the one that does not depends too much on developers remembering to do the right thing all the time. So for example if there is a method that leads to protentional SQL injection or XSS or whatever, prohibit its use and write unit test for it. Basically, static analysis of a code. So then, when someone accidently uses it, the test suite will complain. Hide unsafe things behind internal libraries that force developers do the right thing. Make the right thing easier then the wrong thing. The other good thing are checklists - checklist of ui code, checklist for API, checklist for database, checklist for configuration. In my opinion, if you want assurance about something important, have checking it regular routine part of process and ideally automated. There is always someone who does not know or dont care or is just tired and not focusing. The best compliance is the one that happens automatically as the easiest thing to do.
  - MattPalmer1086 4y ago
    I'm currently working on SDLC security. There's lots of different pieces: peer review, secure code review, threat modelling, training, secure patterns, coding standards, static and dynamic analysis, software composition analysis, build pipeline security, and pen testing! And a bunch of other things to think about. In terms of the developer facing stuff, I'm keen not to repeat the sins of the past where security teams dump a whole load of well-meaning but practically useless stuff on them. As I say, I've been on the other side of the fence. Management and compliance people want assurance that devs are aware of relevant secure coding techniques and pitfalls, but they tend to glom on to big, well known standards, even if half of it isn't useful. I like the idea of finding coding examples relevant to the tech they use, that demonstrates insecure and then secure patterns. For the things that actually make a difference... And then to link the secure coding standards to that as well. Join it up, keep it relevant and practical. Then I just have to demonstrate that this actually meets what the compliance people want to see...
MattPalmer1086 4y ago
I hear you on OWASP in fact. I think the earlier iterations of it were more useful to developers. It focused on very specific vulnerabilities and it was a lot more concrete. Now it has morphed into a much more abstract taxonomy of vulnerabilities and covers mobile as well as web. I think security people love this stuff, but it's much less directly useful to a normal dev. It has very good brand recognition though! Even management types have heard of it, which is unusual for a security standard!