« Go Wide and Deep, Incrementally | Main | To Those About to Engineer - We Salute You! »



I suggest making changes to the way quality testing is done before you can add in secure coding practices.

For example, adding continuous-prevention into the lifecycle is the number one thing companies can do to increase secure coding practices with very little overhead/cost.

Secondly, changing from hiring/retaining Software Quality Engineers (SQE's) to hiring full-time developer-tester(s) (familiar with continuous integration -- coding standards, unit testing, mock objects, code coverage, static analysis, build servers, integration testing with test harnesses). This is mostly a shift towards test-driven development (TDD) and Continuous Integration (CI). Some may feel that this is too Agile (which I don't see how it's tied to Agile, you can use CI with any development paradigm). Also, besides just TDD, behavior-driven development is also worth a look.

I also feel that CWE-Compatible solutions are very important to the secure coding process, but these are mostly integration phase tools and programming phase tools. Even Fortify SCA and Ounce are mostly required to be used during build-time. There are other developer tools such as DevInspect or AppScan DE, but these are too much for any developer. These sort of tools should be run during integration and have their output verified before release. Putting any tools in the IDE besides developer tools (PMD/FindBugs/EclEmma and PREsharp/FxCop/NCover count as development tools) is likely a mistake. Counting on QA (SQE's) to test for security very much is likely a mistake.

As far as the carrot/sticks argument goes... we need to be getting metrics at integration on every developer's components/code and REWARD the ones that consistently avoid CWE issues. Penalizing any of these people is likely to backfire.

I have started to come about face on secure coding. My new interest is moving towards what can be done before the programming phase and integration phase. During requirements/design (especially HLD), tools and inspection can be done in addition to risk analysis. Choosing a framework such as HDIV is going to go a long way, but I've also come about face on secure frameworks as well. Using an ADL such as UML 2.0 is good, but only works on large projects, where you can accomplish a working model and still take up less than 10% of the time and budget of the overall project. Requirements analysis using NASA SATC's Automated Requirement Measurement Tool (ARM) or IBM Rational RequisitePro is recommended for these types of large projects before HLD or UML modeling begins. Afterwards, using Cigital/BSI Architectural Risk Analysis in the HLD with good requirements is going to help significantly. I prefer looking at tools like PTA, TAM-E, or Octotrike for this purpose. After the UML is built, Klocwork K7 and IBM Rational Rose can be used to perform secure design inspection.

Even this is not good enough for me. Design inspection may eliminate 75% of security-related bugs, but what impresses me today is secure software architecture. Secure software architecture means that not only are components and connectors used (e.g. SOA), but that an existing architecture that prevents, detects, and recovers from design vulnerabilities is utilized for the application by design. Unfortunately, I'm only aware of the OWASP ESAPI Project which attempts to build on some sort of standard secure software architecture model. I'm investigating this concept more in-depth now, as I see it as a better future than secure coding, secure frameworks, and secure design inspection alone.

The comments to this entry are closed.