[SC-L] How Can You Tell It Is Written Securely?

[Dana Epp]

Code auditing. Untrusted code cannot be deemed safe. If you plan to
outsource your development you must have implicit trust with that
firm, or you need internal assets that have the ability to complete
the audits separately. There is no magic wand here.

But the same risk can be said to exist with inhouse development. We
all have heard of employees writing timebombs or backdoors in their
code. No difference here. You are just transferring the risk.

If you want to trust the code, you need a process in place where you
seperate code development from code review. In this way, you need a
minimum of two members of the dev team that wish to do harm in your
codebase before the risk elevates.

Of course, the auditor better know what the hell he or she is doing.
Otherwise, stuff will still get through.

-- 
Regards,
Dana Epp
Microsoft Security MVP

On Wed, Nov 26, 2008 at 6:03 PM, Mark Rockman <mrockman at acm.org> wrote:
> OK.  So you decide to outsource your programming assignment to Asia and
> demand that they deliver code that is so locked down that it cannot
> misbehave.  How can you tell that what they deliver is truly locked down?
> Will you wait until it gets hacked?  What simple yet thorough inspection
> process is there that'll do the job?  Doesn't exist, does it?
>
>
> MARK ROCKMAN
> MDRSESCO LLC
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> _______________________________________________
>
>