On 19/06/2013 9:45, Charles Mills wrote:
Without giving away a whole lot of details, the code is in a position such that it could for example (were it malicious) suppress certain security auditing. (Any APF authorized program can basically do anything, of course, but it would be fairly trivial for it to do something like I describe.) So it would not necessarily be in great a position to steal customer data itself, but if we were malicious, and conspired with a rogue employee, we could perhaps jointly steal valuable data.
I don't work with authorized code, but my feeling is that I would not give a customer access to audit code. I can see a number of issues/questions:
* How many customers are actually qualified to detect security exposures in authorized code? * If a customer audits the code, and it was later exploited anyway, does the customer accept any responsibility? * What happens if you allow customers to audit the code, they don't report any problems, but a hole is later expoited at another customer and knowledge of the source code is suspected? * Do the customers need to audit the code every time they install a changed version? Might knowledge of the changes give some indication of weaknesses in old versions?
How many vendors do allow you to audit their authorized code? I know IBM is very reluctant to divulge any information that might allow you to exploit a vulnerability. I would say source code to authorized modules is that type of information.
Ultimately, I think a vendor has to be responsible for the security of their own authorized code. If auditing is required (and it might be a reasonable thing to do) it would be better if it were done by a recognized expert, rather than individual customers.
Regards Andrew Rowley -- and...@blackhillsoftware.com +61 413 302 386 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
