4

I'm looking for a secure software development checklist.

I know that there exists several secure development methodologies (for example Which Secure Development Lifecycle model to choose?), which cover all the steps in software development, but when it reaches the point of "write secure code", they don't specify which elements a normal programmer has to take into account when they're coding.

The only documents that I've found interesing for what I'm looking for (something to advise my programmers what they should or shouldn't do) are: https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf

Do you know any other one?

Thanks.

closed as off-topic by Eric G, Jens Erat, RoraΖ, Iszi, M'vy Mar 18 '15 at 8:38

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    I'm outspoken in saying: skip the C programming and use a memory safe language. – boggart Mar 11 '15 at 15:35
  • 2
    I'm outspoken in saying: if you think memory safe languages don't have security caveats, you should have a look at the above. – Lucas Kauffman Mar 11 '15 at 15:39
3

This is kind of like a product recommendation, so it may end up closed however. You should also be careful to distinguish between a checklist and a standard.

If you are looking for some high level checklists to use for your development process, you may want to checks out SANS SWAT, which covers more logical considerations rather then specific code level issues. You may also be interested in the ISO 27000 (i.e., ISO/IEC 27034) series (not just 27001 or 27002). Other methodologies include STRIDE (would not recommend) and DREAD from Microsoft

It's not clear if this is for a specific programming language, but NASA JPL has guidelines for C and JAVA which may be useful to consider as part of security standards. Oracle has their own JAVA secure guidelines. The CERT guidelines already in Jaques answer are also in the same realm.


You will need to clarify your objectives and build upon these tools to create:

  1. Secure coding standards (code will be formatted this way)
  2. Library/platform specific standards (CSRF tokens will use this common function)
  3. Secure development/SDLC practices (code will be put through these scanners, tools, or processes before being committed; pen test before promoted to production)
  4. Ongoing testing and review (regularly occurring application re-certifications; responsible disclosure procedures)

A checklist might be a good way to start as it is clear cut, but bad processes can be just as harmful - e.g., you promote the wrong branch with the buggy code).

1

It's impossible to get secure code by defining a set of rules to comply with. The CERT standard that Jacques links to is a good example of this. It does list "bad things to do", and I glancing through it I didn't find anything I particularly disagreed with. But the list is so long and many of the items so esoteric and generalized it's relatively useless other than as a reference material like a dictionary.

There's probably really no good methodology that's simply going to get you security. Security comes through developers being knowledgeable about security as well as working in an organization where security is valued. If your organization doesn't understand security, you're not going to get any.

The best you can probably do is encourage secure development by example, and through code reviews. You need knowledgeable people to read through code before it gets into your product and provide constructive criticism. Encourage your developers to at least understand the Owasp top 10. Some are going to be better at it than others.

Security is about culture, not about lifecycles or rule following. You can't define security, as it's always a moving target and different for each situation.

0

Take a look at Microsoft's SDLC. They recommend using static code analysis tools to catch the simple stuff, like arrays out of bounds, etc., and use dynamic fuzz testing to help find the harder stuff. But they're also relying on their programmers bringing a high level of competence to their task.

If you're looking more for plaintext advice and guidance, look at "Secure Coding in C and C++" by Robert C. Seacord. The middle third of the book is devoted to a detailed list of problems and solutions, and appears to be the "checklist" of items you're interested in.

0

The CERT team of the software engineering institute at carnegie mellon university has a secure coding standard for C, C++, Java, Perl:

https://www.securecoding.cert.org/confluence/display/seccode/CERT+Coding+Standards

It tells you precisely what programmers should do or not, as you mentioned. For instance:

Do not apply the sizeof operator to a pointer when taking the size of an array

For every rule, it gives good and bad code examples, and an explanation of the risks.

0

Gunnar Peterson did a prezo (available via YouTube) that he elaborated further via his blog post on Process not Outcomes. I enjoyed this approach and the comments as well.

The OWASP Proactive Controls and OWASP Periodic Table of Vulnerabilties are checklist approaches that work great at building security in. Jim Manico did a great presentation on the OWASP Proactive Controls, available at this YouTube location.

Here are some mappings from the SANS SWAT checklist categories to AppSec Principles, OWASP Conucopia, and the Proactive Controls projects.

Not the answer you're looking for? Browse other questions tagged or ask your own question.