Every enterprise will need security policies to define the best practices in security for its development teams. One of these policies is secure coding. You will be the custodian of these best practice documents (or checklist) and update them through the evolution of the technology. Whenever possible, the secure coding guidelines should be shared with developers in the organization through the intranet website of the company. If this document doesn't exist, it is your job as an application security professional to make a new one and suggest it to management, and believe me, they will appreciate it big time. Some companies encourage the idea of going through secure coding training for developers to engage them in that process. You can refer to the secure coding checklist section in this chapter to get ideas on how to develop your own secure coding guidelines for your company (as a consultant or employee).

There is an important topic that I mentioned in the previous chapter—SDL. This is a topic that I want you to master and understand how it works in practice, because secure coding is a prerequisite to SDL, and during the development of a normal project, secure coding should be used at every step, as follows:

1. Architecture phase: At the beginning of the project, the architecture will be defined and the secure coding practices document will be used as a reference for all the technical challenges.
2. Development phase: During the development phase, continuous integration will be used and executed every time the project is compiled on the build server. The static code analyzer will scan the code automatically after each build, and if the developer hasn't respected the security guidelines, the scanner will most probably flag it as a flaw. We will talk in more detail about the automatic scanners later in this chapter.

3. Before gating: Before the deployment in the production environment, you will execute different tests (Web Intrusion and manual Source Code Review). At this stage, you can reuse the secure coding guidelines to enforce your arguments against the project team members (web application project) who will surely say that no one told them about this before.