racheljoi.com

why testers need to be involved from the beginning

On a recent project, the vendor’s software was going to be embedded in our website through an iframe. After a quick tutorial from my husband (a software architect who had done a lot of research on the security of iframes not too long before that), I thought it would be interesting to poke around and see what I could find in their system and see if I could break into it, though I’m not a security tester. I found some of what I expected to find – they were using security headers that are a little dated but the best that work on Safari (there’s more secure stuff for the other browsers – I don’t know why Apple is behind the times on that). But there was also a header that was misspelled when it should have been automatically generated by the system. This gave me pause. There was a possibility that something got a little funky with the server, but it was also possible that they were hard-coding things on a homegrown server rather than using a commercial server that is regularly patched.

I filed a bug. And pushed it. A lot. I got the Information Security team involved. The response finally came back (after more than a month of asking) that they were not using Apache, but they couldn’t tell us more about it, that they were keeping up with security issues and regularly testing their server. This was another issue. The software we were given was so poorly written and tested, that I wasn’t sure if we could trust their word that they were adequately testing their own servers, much less keeping up with OWASP vulnerabilities or doing anything security-related.

InfoSec was aware of this. But when I asked about the results from their penetration testing, the project manager told me that they weren’t doing any testing. It was in our contract with this vendor that we wouldn’t do any testing of their server.

Seriously? My response to that in a meeting was, “Someone is touching their servers, and I’m concerned that it’s not us.”

I lost the battle. I looked through the contract to see if there was any way we could say they breached the contract (hooray, law background!), but the vendor had written it so wishy-washy that it was basically a “best effort” contract without anything binding. So frustrating.

In addition to the gaping potential security issues, it was a big problem to me that testers weren’t involved in the decision-making process. I’m not sure if anyone technical was involved, though I really hope so. But a tester could have raised the issue about not testing their servers instead of lawyers and business people just agreeing to it without considering the implications. It should have been a major red flag that they didn’t want us to try to break into their server.

Testers are not just a checkmark. We have experience and specific knowledge that can assist with product decisions and can end up protecting the business’s interests.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.