Jordan Wightman wrote:
<>>Which might help in finding the smaller, newer bugs that have >been introduced by the new chunks of code. However, this won't help >you at all if the program is reasonably complex, as you may get subtle >interactions between new code and old, adding both potential security >holes and mandelbugs.
The auditing here are mainly focused on security holes and breaches.
Also, the OS codes are modular. Remove all modules that one do not
need. This is how one does it in building OS where security is paramount. When
something goes wrong, one will have less codes to compile, peruse and evaluate.
Test programs will complete quicker and one will have plenty of time to
check.
For example, when building bridge-firewalls out of Linux the kernel and modules will become a tiny fraction of the entire codes after one has gone through eliminating the codes that are not required. It will fit into one floppy diskette.
It must be noted that manual inspection and analysis is only one process. The auditors have automated tools that they use to audit in addition to queries and answers as well as other tools like field testing, etc.
After all these, the auditors then make their judgement, to accept the software,
or require modification, or accept, or even reject. Let us take the extreme
scenario of complex changes to software that the auditors are unable to
comprehend the changes, then the auditors most certainly will reject the
changes. If the auditors can't comprehend how many others can ?
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
