[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
said:

> "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
years
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



Relevant Pages

  • Re: Solar Power Satellite Concept
    ... of these sorts of concepts that never make it into production because ... without giving any reason! ... June 10, 1964, almost no one was watching as a vehicle entered the ... led by a young chief engineer named Bill Kinard. ...
    (sci.space.policy)
  • Re: Walkers damage the planet
    ... It's the reason it's not a reason. ... The comparison is between the CO2 emissions for a car, ... production cost is due to energy and therefore fossil fuel usage and CO2 ...
    (uk.rec.walking)
  • Re: Is Linux A Feasible Platofrm For Professional DAW work ?
    ... the requisite skills to build their own furniture, ... furniture built by people who need help plugging boxes together. ... I see no reason to continue polishing turds. ... let's differentiate between performance turds and production ...
    (rec.audio.pro)
  • Re: Walkers damage the planet
    ... into food in general - see above. ... It's the reason it's not a reason. ... The comparison is between the CO2 emissions for a car, ... production cost is due to energy and therefore fossil fuel usage and CO2 ...
    (uk.rec.walking)
  • Re: [fw-wiz] VA vs PT tool
    ... >However, a VA tool is limited, in that it only stops at the vulnerability. ... what I use myself and what my customers have purchased) are Nessus, ISS, ... something on a production network, ... I've used it on plenty of production networks, ...
    (Firewall-Wizards)