However, I am going to use “Secure SDLC” as the popular description, SwA (Software Assurance) as the description for what is actually is, and “secure inspection” to refer to the ten parts necessary to complete a proper life cycle:

(1) Secure requirements inspection (using Fagan inspection)
(2) HLD’s with secure software/information system architecture inspection (using Fagan inspection on formal specifications, semi-formal specifications, or informal specifications such as using an ADL e.g. UML 2.0)
(3) DLD’s with secure design inspection (using Fagan inspection along with DFD’s, attack-trees, attack-modeling, and threat-modeling after architectural risk analysis)
(4) Secure code inspection during programming (using Fagan inspection along with unit testing and code metrics)
(5) Secure code inspection during integration (using Fagan inspection along with a test harness)
(6) Secure system test planning (using Fagan inspection)
(7) Secure integration test planning (using Fagan inspection)
(8) Secure functional test planning (using Fagan inspection)
(9) Secure acceptance test planning (using Fagan inspection)
(10) Secure operations/maintenance test planning (using Fagan inspection)

I see operations as a different organization and with a different methodology (i.e. systems life cycle instead of software life cycle). According to the above, quality testing or security testing can be integrated in the life cycle or remain separate, but all concerns should be covered.

This doesn’t take into account “Secure by Deployment”, which I feel is not part of the SDLC, but instead part of the operations methodology (The Art of Software Security Assessment’s Chapter 3 – Operational Review).

I dislike using the word “application” or the words “application security” because those words denote a deployed application (as opposed to software which is made up of components to be built during system integration). A deployed application should have known vulnerabilities and be under a vulnerability management program. This is an operations issue – not a development one.

When performing secure software/information system architecture inspection (my #2 above), this practice is much different than the Operational Review. Many note that ERD (entity-relationship diagrams) should be used, but many modern languages preclude ERD’s because they utilize annotations/attributes/pragmas/metadata in order to describe schemas that are then optimized by the language on the fly.

There is a lot of confusion about which tools to use where in this process. Requirements inspection can be done with NASA SATC ARM 2.1 (free, open-source) and IBM Rational RequisitePro (commercial). High-level design inspection can be done with Klocwork K7 (commercial), IBM Rational Rose (commercial) or later with Fujaba (UML and Java open-source) or any UML tool. Detailed-level designs can be done using Microsoft TAM/TAM-E or Octotrike. I suggest Trike or OCTAVE for the architectural risk-analysis instead of STRIDE or a rating system (e.g. DREAD, CVSS2, CWE Scoring, et al). All of the design portion should only take up about ten percent of the total time and budget alloted to any specific project.

Programming tools can be used inside of the IDE during programming if the IDE supports this sort of feature, or available before build(s) in the revision control system. Examples are too numerous to include for every language but probably should include at least one form of binary or bytecode inspection (e.g. FxCop, FindBugs, Veracode SecurityReview), one form of source code inspection (e.g. PMD or Presharp), one way of unit testing (e.g. CT-Eclipse, Crap4j), and one method of gathering code metrics (e.g. Java metrics, NDepend). These tools don’t have to be security specific, but some are (e.g. Veracode, Ounce, Armorize, Fortify SCA) while others come close to a mixed bag (e.g. Klocwork, Grammatech, Coverity). The programming phase usually takes up most of the budget for all the wrong reasons, so be sure to fire/force-lateral-move all of the programmers either during or right after the project.

During integration (i.e. the build, especially any continuous integration or nightly/daily build process), the tools should be security-specific if at all possible. The test harness often comprises itself of unit tests, component tests, mock objects, spies, and code metrics. It could also include structural (usually static analysis), system (working environment whether staged or production), and functional testing (usually dynamic/runtime analysis) depending on the specific application being built. Integration testing for security should take up most of the budget of the security portion of any project, but never does. I would spend eighty percent of the budget on automated tools and processes that work exactly like a Continuous Integration program, but with added software assurance in and risk-management out.