There are a lot of great perks that come with being a developer. On the upside, I enjoy the challenge of developing solutions to real world problems with peers in UX, PM, QA, Ops, etc. I love the creative process and the energy a team has when we are firing in the same direction at the same time. I love building the stuff and making the team hum. I love that sense of accomplishment we share as a team when we do something that works and the knowledge that humanity gets a little more efficient every time we deliver. In addition, the satisfaction I get from seeing my project through to completion is something that brings me a lot of personal joy. All things considered, I’d say I’m satisfied with my career life choice.
In addition to showing up on time with a functional solution, I’m also required to make sure it’s fault tolerant, scalable, maintainable, testable, and secure.
As a professional developer, I have to be very concerned with schedules. Specifically, I’m measured in my job performance about delivering features and functionality on a (relatively) predictable date. This is one of the downsides of development as it brings a bit of stress and anxiety to my otherwise awesome day. There is always that schedule pressure hanging around. That part I’d like to forget about, but I understand the realities of business and why we can’t completely abandon schedules. I understand we have to ship things that might not be perfect in order to meet a deadline, save a deal, demonstrate more value than a competitor, or whatever.
So, I took that information and being a scientist, started to create a series of hypotheses. I started inviting them to project inception meetings. These are the type of meetings where you’re trying to identify a problem that needs to be solved and determine if it’s worth pursuing a technology solution to meet the need. During these sessions, it was the “Security Team” that had the deer in headlights stare. They’d tell me, I don’t know where to start my security analysis if there isn’t something tangible I can poke at and examine. I asked, “Too early in the process…” and they’d say “Yup, come back to me when you have something I can put my hands on.” I’d say, “You mean when we’re ready to ship?” and the answer was “No, sooner than that.” I would ask, “Could you be more specific?” and the answer was usually “No.” Awesome, right? Very helpful.
I’ve come a long way since then, and so has the AppSec industry, but the nature of the problem still remains. It’s a chicken and egg problem. Developer: “Is my application going to be secure and can you tell me where the risk to my schedule is?” Security Team: “No, but when we see something wrong with what you’ve already done we’ll be happy to tell you.” Developer: “Can you quantify the risk to my schedule and help me mitigate that risk or tell me ahead of time what not to do?” Security Team: “No, just write secure code.” Developer: “What the heck are you talking about? I’m leaving to go learn SWIFT. Let me know when you’ve figured out what I should be doing. I’ve got a release date to hit.” Sound familiar?
So, security team, where can you change the nature of this problem and stop letting me down? Give me something that allows me to spread the project risk across the entire release cycle (however long or short that is). That’s my risk mitigation strategy of choice when I can’t eliminate it. Tell me as early as you possibly can when something is wrong. Speak my language and integrate your security program into my existing workflow. If I’m going to take on the responsibility of making my application “secure” to help you, you’re going to have to bring something to the table that helps me. Don’t be a drag against my schedule and backload all the risk until the end. Raise problems early and help me do my job, and I’ll help you do yours.