In my last post, I talked about a scenario designers and developers know all too well: well-meaning management, project managers, architects, and business staff who don’t believe security is important — or don’t believe it’s important enough to warrant your time. Many of these doubters have direct input into the amount of effort you can spend on a project. If you’re a developer who knows what can happen when you ignore customer’s demands for reasonable security, what can you do?
First, let me address a tendency we have as developers. You are burdened with knowledge of how to get things done.* If you’re security conscious, you understand what insecure code or coding practices can do to customer trust. We tend to get frustrated or angry when people try to override our coding experience with their own priorities.
Becoming angry, though, won’t help. At best, they’ll just ignore you and label you a prima donna. At worst, they’ll just call you a prima donna and put you on work improvement because you’res not being a team player (in their eyes). But if (justifiable) anger’s not the answer, what is?
Back in 1997, a modern philosopher named Don Miguel Ruiz came up with The Four Agreements to guide how we interact with others and ourselves. I’ve found them to be an effective way to advocate for security on behalf of the customer. Those rules are:
Unfortunately, that last point is important: Sometimes, despite your best efforts, despite your eloquence and tenacity, despite your well-reasoned arguments and appeals to customer satisfaction, the team may decide not to incorporate the necessary security controls. They might elect to allow unfiltered input under the reasoning that the code uses stored procedures, so it’s safe. They might not understand that the input might include cross-site scripting (XSS) attacks that could ensnare a browser displaying the data. After all, security is only as strong as its weakest link. What can you do then?
As I see it, you have two choices:
The real shame is that writing secure code is not materially different from writing insecure code. In fact, I’d argue that it’s actually less expensive, since the resulting code requires less operational support and is less likely to embroil the company in an inadvertent data disclosure. Those things take a lot of time to manage and correct! And that’s not even counting potential legal fees as the US Federal Trade Commission begins to get involved.
Always advocate for doing the right thing. It sometimes doesn’t seem worth it, but you have to live with you, so you might as well act in a way you can respect!
In the next post, we’ll take a look at giving your security concerns a sound foundation.
* After all, we’re the ones who tell the program exactly what to do and when to do it. The business team has more knowledge of why things are happening, but when it comes to exactly what’s happening, we’re at the epicenter.