It's only a matter of time before someone finds all the skeletons in your closet. In this case the "someone" is a hacker and the “closets” are your applications. As if that isn’t scary enough, consider all of the 3rd party applications and libraries being leveraged to make your applications function…and all of their skeletons you don't know of. No bones about it, there’s a whole heap of issues that can no longer accept failure as the norm.
I saw an awesome request from a local OWASP chapter last week: “Bring a developer to the next meeting day!” For real, way to go! The sooner everyone learns that security is a journey that ultimately is the responsibility of all who are involved from creation to deployment, the better off we will be. In order for change like that to happen though, this is where we are going to get uncomfortable. No one said a secure approach was going to be fun, but I will say that it doesn’t have to be the heaviest of burdens to carry…and you certainly don’t need to carry it alone. I tried to figure out who could relate to that statement, but no matter which perspective I tried to look at it from, I came to the same conclusion: it should echo across the board. (No pun intended)
A developer’s job has always been to write functional code. Security teams have always been isolated from developers, but yet they are the ones held accountable when a breach occurs at the application layer. Plain and simple: developers are, for the most part, not security focused, and we security folks are, for the most part, not coders. When it comes to application security, this is where we need to redefine what quality actually means. It’s super easy to point your finger at security, but when they aren’t brought into the picture until it’s too late…what are they supposed to do? Let’s take a minute to put this into perspective. If there was a new prison being constructed in your neighborhood, do you really think it would be acceptable to talk about where the locks, gates, and controls go AFTER it’s been built? Not a chance! That logic applies here and this is why CA Veracode exists.
I have talked with enough developers out there since joining CA Veracode to know that this is not what most of them signed up for. They are all extremely good at their jobs, but are overwhelmed at the mere thought of adding another 'thing' to their plates and still produce. The demand for this type of knowledge has been around long enough where there is a middle ground…..developers can learn in increments within the code they are producing, then take the results and address them in real time. People like us learn better by doing anyway! We know that an SDLC can get pretty aggressive, and with that comes stress. Security isn’t meant to add to that, it's going to end up reducing the workload that will come in the end when those skeletons are no longer hidden. If an organization has developers on their team who are coding securely… talk about ninja status!!
With all the compliance standards and certifications we have today, it’s a shame there haven’t been more calls to say that quality doesn’t just mean functional anymore, quality has to mean secure. I won’t say I’m surprised either, but I refuse to let security continue to be the butt of jokes anymore….at least not until the security umbrella starts to cover development. I always say that it costs more to un-embarrass yourself than it does to just be proactive….so where’s the beef?
Keep fighting the good fight my friends!