[WEB SECURITY] code review techniques for when you don't trust your developers or testers
Mike.Duncan at noaa.gov
Thu Aug 20 16:07:48 EDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Mat Caughron wrote:
> Have we all attained the realization that static analysis is where the
> real work of appsec gets done?
Oh yeah. I find it hilarious that most security firms rely solely on
dynamic scans to this day to give them a complete picture of application
> I'll argue that source review (automated, manual) and enlightened DBA's
> are broadly better at solving the insider threat problem than dynamic
I would argue the same with the additional caveat that without regular
training, the tools can only provide so much, so a developer's
protection (the tool and their knowledge combined) blanket is limited.
> Would love to hear from others who have been successful at uncovering an
> insider threat with source code review/static analysis.
> Specifically: what worked, what didn't? How helpful, or not, was
> version control or other typical controls around the development process?
Primarily, as a developer for a long time and now a AppSec specialist, I
found that development from project to project brought about limited
scope to the developer for the said specific project. So, an outside
developer or auditor should always be used for application reviews.
Additionally, as I stated above, training is a must for all developers.
Relying on the tool(s) to do all the work will never fully protect the
applications/systems because the tools really lag behind on most of
their scans. Fortify for example, will do a great job telling you that
something is not sanitized properly, but then fail to tell the developer
that they are properly authorizing the user for a specific zone of the
application. Tools have limited knowledge of the business and project
The auditor, although not a developer for this project, must be a
developer or have been one in the past really. I have found in my time
as an auditor there are too many people whom don't know the language
constructs, libraries/dependencies, and/or technologies being used to
effectively provide audit information. They often rely solely on the
tool to provide all the information and we all know what that will lead
Also, and I know I am rambling here but, the auditor should be familiar
with the project and business requirements for it. The auditor should
know about the technologies being used before the first audit so they
can effectively drive the developer(s) in a more secure fashion from the
beginning. All too often the development begins, the auditor then is put
up against a business objective (deadline) and everyone then starts to
blame security for being the reason for development time-line failures.
It is a lot easier for application patching as well if the developer(s)
are using proper source control. The auditor can then just look to
changes from a good/gold version of the code. Also, the auditor will be
able to decrease the time for the audit, knowing the language and
constructs behind the project, because the changes are arguably much
smaller. I have found personally, that patches/updates to existing code
is much easier and does not require a complete source code review using
a tool at all most of the time. But, I do complete [bi-]annual code
audits to ensure that (forgotten) projects are protected against newer
threats. If the changes to the code are great, requiring a major version
numeric change, then I will use tools as well.
Great topic. Thanks Mat.
Application Security Specialist
National Climatic Data Center, NOAA, US DoC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Join WASC on LinkedIn
More information about the websecurity