Make it clear that security is a cost like any other in SDLC
Security shouldn’t be seen as “addition” to the product development. It’s a part of it like all other activities and can be counted as a part of Quality Assurance, because nowadays customers demand high quality products and safety is one of elements defining quality.
Middle-management is more eager to spend resources on security, when they perceive it as a regular, necessary cost of software development, because there is never enough money and time to invest in “additional” activities. Security is often perceived as a no-ROI time-waster which adds complexity and slows down development process. Unless you explain how and why security is important you’ll have tough time pushing security related changes into existing SDLC.
Settle down on how much resources — especially time — can be dedicated for security improvements/fixes. Discuss how how many hours in each development sprint can be dedicated for security and how much free bandwidth does engineering have for potential unexpected security patching.
It’s not reasonable to expect business to stop all money-making activities and focus entirely on security for a few days/weeks to fix all identified vulnerabilities. Use risk management to help business operate instead of expecting impossible.
To make things happen you need to focus on small but constant improvements by e.g. establishing fixed amount of resources that will be spent on security in each product release/sprint. Sacrificing 2–5% engineering time — in each sprint — for security is less painful than telling the customer that you won’t deliver a mission critical feature because for a next few weeks you must deal with unreasonable requests of security department.
Build secure SDLC
Security is more cost-effective if you start working on it at the earliest phase of SDLC.
Old and common practice “let’s build the product/infrastructure and then throw at security team” is hard to scale, expensive as you need to write code twice instead of securing it in the first place and doesn’t drive long term improvements as developers will likely make same mistakes over and over again.
While that approach was somewhat practical in the past, nowadays lots of software is too complex for security teams to secure the product in just few days before it hits production.
Surely there are small software houses with senior, security-savvy engineers where it’s practical to build a tiny product and then deliver it to security testers. This is fair, however if that approach didn’t work for you you may like to take an approach in which you inject security into whole software development life cycle and my recommendation is to get involved in product design phase and keep an eye on the product throughout the whole development process.
Show up, adapt and deliver results
Everyone needs to be aware that security testing takes quite a lot of time, and it must be included in release schedules’ planning.
A good idea is to jump in with final security tests when QA Team is given time to do their testing. Asking for separate time after everyone else is done would be pain and would significantly lag shipping process which is something we try to avoid whenever possible — one of upmost important rules of effective security is to avoid slowing anything or anyone down.
You can show your presence at the company/team e.g. by dropping suggestion here and there, by asking people out of the blue if they need your help, by plugging security automation into Continuous Integration process so you immediately learn there is something new and can have tests run accordingly. Show them that you’re watching over even those things they didn’t report to you and it’ll build respect for your efforts.
If people see you hanging around all the time during design discussions, they’ll organically learn you’re needed and will let you know whenever there is something coming up. Just be there for them and make it easy to approach you and ask for help.
Professionals like other professionals and if you become one and build such image of yourself, others will be more eager to help and collaborate with you.
Dawid Bałut 