[fw-wiz] Code review/audit and/or version control

From: George Capehart (capegeo@opengroup.org)
Date: 07/22/02

From: George Capehart <capegeo@opengroup.org>
To: firewall-wizards@honor.icsalabs.com
Date: Mon Jul 22 09:07:01 2002

The comments below were taken from an out-of-band exchange with the
moderator after he rejected a comment I made early in the thread on FWTK
and smap. The conversation took an interesting twist, and when Paul

> "I agree, and again- I'd *happily* approve a longer posting. I think the
> issues are important, and while it's a little off-topic, I don't think
> it's horribly so."

I thought I'd take him at his word. ;-)

The topic got around to the problems of managing code integrity, code
reviews, version control, etc. through the complete life cycle of a
system. It touched on reintroducing buggy code into the production
branch, even knowingly . . . "re-auditing" code, etc. I have included a
section of the last message below. Using that as the basis for
discussion, I'll take the straw position that code that has been
"audited out" of a distribution because of quality or security reasons
should not be allowed back in.

< ----- Begin excerpt ----- >
> Wow! That's interesting. On a Y2K project, I ran into some code that
> had been around so long that no one knew where the source was, but I
> don't think it was that old . . . Incredible. I'm sure that the reason
> the DBMS was still in use is that it was a robust product. In the case
> of the Y2K project, no one was willing to take it out of the job stream
> 'cause no one knew what it did . . . ~<8-}

That's typically how it goes! Back when I could make patches by looking
at object code, my threshold for mucking with things was way different
than it is now ;)

> Well, I don't know about that particular environment, so I can't say.
> However, for the system I described above, the *absence* of
> source/version
> control made even code review impossible . . . excepting, of course the
> disassembled object. It's been a *looooong* time since I've written
> assembler for any architecture, much less the System 3xx . . . ;-)

Thank goodness the DBMS job was the last time I did that, after 4.5
of mostly assembler development, I think I was as happy to leave it as I
was when I started it to get the job. I haven't touched PL/1 since 92,
and 3x0 assembler since about 93.

> For me it is not a zero-sum game between code review and version
> control. I'm afraid that I might have given that impression. I do
> understand the need for resurrecting old code. However, I do not
> understand the need to resurrect code that has known memory leaks, bad

Better the leaks you know than the ones you don't? It's not a *good*
reason, but I've seen it done before.

> There is another reason that code review is important to me. When a
> system is initially designed and constructed, the requirements, design
> and implementation decisions are based on assumptions about the chain of
> trust and controls that are going to be in place when the system is put
> into production. Over time, as systems evolve and vulnerability
> profiles change, those assumptions can become invalid. This means that

That's a very important issue which is overlooked way too frequently for
my tastes. It's one of the reaons I preferred to have a good ongoing
relationship with my vendors- so I could say "Hey, I'm looking at doing
foo, is that going to change this assumption?"

> systems that were "secure" when implemented are not any longer. So, for
> me, whenever a system is modified, one should do a review of the
> potentially vulnerable parts of the legacy code. So, I'm definitely not
> saying that code reviews are not important. What I should have more
> careful in saying (and admit that this *is* a matter of religion) is
> that it is my personal opinion that code that has been audited and
> rejected because of poor quality or because it contains known
> vulnerabilities should never be allowed back into the production branch.
> ;-)
< ----- End excerpt ----- >

George Capehart