frosting on a cake. It’s something that can just be “brushed on” at the very end of the development process. These are often the same organizations that cut security altogether when release schedules threaten to slip, but that's a subject for another article. The problem with this is that the further you are into the development process, the more costly it is to fix security vulnerabilities.
For example, suppose that you developed a shopping cart Web application that keeps data about the current state of the cart in hidden HTML form fields in the page. You ironed out all the bugs and then sent it to your security penetration testers to be checked for security before it shipped. Fifteen minutes after you sent it, they noticed that one of the parameters being stored in the hidden (but user-changeable) form fields was the item price. Thirty seconds later, they were filling up their shopping carts with brand new plasma TVs for one dollar each. You're now forced to go back and redesign the application, potentially throwing away weeks or months of work, thus requiring a whole new cycle of architecture, implementation, verification, and penetration testing.
Again, the solution to this problem is to introduce security earlier in the development lifecycle. Instead of brushing security on at the end, you need to "bake in" security from the start. Before you even write a line of code, spend some time threat modeling your proposed design. Use the STRIDE threat category system (Spoofing/Tampering/Repudiation/Information disclosure/Denial of service/Elevation of privilege) to help brainstorm potential threats to your application. There are several threat-modeling tools that can help walk you through this process and that are free to download, so they won't break your budget.