I think the final goal of code auditing is helping to make better code.
In the long term, it is more important a successful project with robust
code than a successful 'code-audit'.
The code-auditing must promote robust code, defensive programming and
'teaching lessons', not to detect guilty people, and the guidelines for
this are under the 'common sense' label. We can learn the lesson of
Quality assurance from other industries, the japanese car industry
revolutionized productivity with the 'Zero-defect' initiative, of each
member of the team -and the company- being a Quality Auditor, instead
of supervising the project 'after the facts'.
- Take the problem before it is born, then it is easier to deal with,
and it resolves itself, paraphrasing Lao-Tzu.
- Start early in the development process: it is better if one starts
working with the team before the project begins, and is part of it
(being everyone informed of our auditing or supervising activities).
One is better positioned if is part of the team - even at the risk of
losing some objectivity -.
- One could anticipate the problems by way of suggesting 'A
methodology', a set of rules or 'best practices' to the developers at
the beginning, this will reduce the 'stress' level of the participants,
and make them more collaborative. And fewer defects will be detected,
because there are less, not by problematic relationship with the team
and obscurity.
- Auditing must be like 'a movie' which helps in building the project,
instead of a 'post-mortem' picture of what was wrong. Of course there
will be situations when there is no alternative than do a post analysis
of what went wrong, but we need to keep focus on the long term, and use
the pareto's law (80/20) for an approach.
- We need to support development methodologies which promote
peer-review, pair programming, such as 'eXtreme Programming' or XP,
which in general are more robust practices and better at 'defensive
programming', are more proactive methodologies, and easier to follow
too. And when dealing with a team which have such practices, they will
not be 'at a defensive position' because they will see you as part of
the process, and as part of their team. Then the whole team (including
the code auditor) will be successful.
Best regards,
Javier Blanqué
-----Original Message-----
From: Yvan Boily [mailto:yboily@seccuris.com]
Sent: segunda-feira, 30 de agosto de 2004 14:45
To: secprog@securityfocus.org
Subject: "Selling" a code-audit.
One of my primary responsibilities with my employer is performing code
audits; so far I have been fairly effective in a technical capacity,
however
on almost every single code audit I have participated in I have
received
hostile responses from the development team. I have tried a variety of
approaches to develop a stronger rapport with the development team,
however
in spite of my best efforts I find that going into a code audit I am
already
fighting against preconceptions about why the code audit is being
performed.
I understand that many people feel threatened when work they have done
is
criticized; what I need to know is how I can minimize this and coax the
development teams into being more interactive than defensive. Any
pointers?
Yvan Boily
