Discuss the significance of the OWASP Software Assurance Maturity Model (SAMM) in establishing secure software practices within an organization.
What is the purpose of a Software Security Champion within a development team, and how do they promote security practices?
What are the key differences between functional and non-functional requirements in software development?
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:
- Secure coding standards (code will be formatted this way)
- Library/platform specific standards (CSRF tokens will use this common function)
- Secure development/SDLC practices (code will be put through these scanners, tools, or processes before being committed; pen test before promoted to production)
- 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).
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.