My first corporate job was with an IT firm, and I was all of 21.
I was hired as a Test Engineer. I did a lot of manual testing, but I’d always had an aptitude for coding and had won many programming contests in my Undergrad years, and I just kept trying to automate all my manual test cases.
I was good at what I did – and I discovered that the better I was – the more the Developers hated it!
My lists of documented bugs were essentially telling them that their code wasn’t doing what it should, and yes, also doing what it shouldn’t do!
Six months, I got a break, and I was absorbed into the Developers team.
And I daresay my experience as a Functional Tester helped me be a cautious and careful coder.
Even while I was designing and coding modules, my mind would automatically churn out the test cases I would run against it in my Test Engineer avatar.
Yes, I wrote good code, and yes I had minimal bugs in the software I designed.
And more importantly, I realized how necessary it was to understand both sides of the picture to improve software quality.
Fast forward ten years, and hundreds of developed apps, and tens of thousands of lines of code, and I had stepped into the Security world. A whole new world you’d think.
Yes, Infrastructure Security certainly was. But AppSec, that was my realm, and something was disturbingly familiar about the dynamic of inter-team relationships.
Security teams were disdainful of Developers. And the Developers abhorred the Sec folk who break their coding rhythm to point out security errors, play havoc with high-priority production deadlines with their security reports, and yes, essentially tell them that their Baby is, well, Ugly.
Yes, I’ve been a developer. For many many years. I understand deadlines, high priority releases, shortened development cycles, functionality above all else, and the darned scope creep.
But yes, I’m also a Security person. I know how alarmingly common the OWASP top ten vulnerabilities are, how advanced exploitation tools and processes are, and how just one security lapse can lead to a nightmare of financial losses and irreparable reputation damage.
And more than anything, I understand that it is necessary to marry the two processes.
For both teams – Dev and Sec – to know they are working towards the same goal – Secure, Functional Code – delivered to meet a deadline.
It is not about one manship, it is not about egos, it is not about a narrowed view of job functions – but being invested in the whole process and working together as partners through the whole SDLC (yes with the QA folk, let’s not forget to invite them to the party!) and making this happen right, the first time!
A talk ask you say?
Perhaps! But necessary.
As necessary as putting down “security” in the requirements gathering phase of the SDLC, and following through.