Internal project plans - SonarQube Tutorial

- [Instructor] Incorporating static application security testing into internal project plans is a terrific way to keep costs down while building security in. With application development methodologies, expecting developers to move more and more quickly though, when does it make sense to develop a project plan at all? Project plans are pretty common in shops that use the waterfall methodology and they even have a home in agile environments. DevOps is another animal entirely. Regardless, there are two scenarios where you'll find value in project planning, even if it's just an academic exercise. Brand new deployments and significant changes to existing apps. Brand new deployments are easy to identify. If it didn't exist yesterday, and it's going to exist tomorrow or next week or next month, then it's brand new. Significant changes? Yeah, that can be a little tricky. When you want to determine whether a change is significant, keep focusing on what's new. Are you adding entirely new functionality to the app? Are you rewriting any part of the code in a new language? A yes to either of these questions is a good indicator that the change is significant. In 2016, Forrester Research published multiple papers on application development and security. They found that the earlier you address application defects, the more money you save on remediation activity down the line. More to the point, those costs will be anywhere from five to 15 times less. But this wasn't news to US-CERT. The United States Computer Emergency Readiness Team had been publishing guidance on how to attain software assurance for years on their build security and website. Although that resource is no longer available online, you'll find that many of the principles that they set forth regarding the relationship between software assurance and project management still hold true today. So all that knowledge about software development methodologies that you picked up earlier in this course, here's where you begin to apply it. Each methodology includes a means for collecting requirements. Create a task for security to ensure that security is engaged here. Security requirements need to be documented so they can be balanced against functional requirements. As analysts begin working with users to design the application, security should be assigned a task to participate as well. The key difference though, is that security should look at the design from the standpoint of a malicious user. This will provide them with the insight they need to propose security test cases for the dynamic security testing to be conducted later in the project. Finally, you should document a task for someone to perform source code security reviews. Automated reviews are ideal and they need to be performed before developers check code back into the code repository. It's also a great idea to kick off an automated code review when the developer steps away to grab a coffee or an energy drink. Let the code review tool do the heavy lifting while the giving their brain a much needed break. I'm also a diehard fan of both clarity and accountability. If you want to ensure that these tasks are executed correctly, you need to answer three important questions. Number one, what is the task? Make sure you've clearly defined exactly what needs to happen, manual or automated, as well as an expectation of the outcome. Who was responsible? Individual accountability is everything. I don't care if you have a team of 50 developers and six project managers. You need to make sure that one and only one person is ultimately responsible for the task. And when is it due? Whether your when is a specific due date or another project task that can't happen until this one is completed, you need to be clear about when the task needs to be done. If you're the security tester, and not the project or product manager then I recommend you take the following actions. First contact the project or product manager to identify security touchpoints. Based on your current understanding of static security testing and your understanding of application development methodologies, you're ready to have that conversation. During the conversation, focus on identifying static security tests that will help you build security in. You and the PM have the same goal here: Software assurance. Talk about the relationship between security and quality. Steer the conversation toward tests that will return the maximum value with minimum effort. Since you're focusing on static testing now, lean heavily on where you can inject source code security reviews into the process. Remember, source code reviews are not the same as source code security reviews and while manual reviews are a good start, automated reviews are the ultimate goal. We'll talk about source code security reviews in more detail later in this course. For now, your goal is to ensure that application security is a consideration during the project planning process. If you're talking to project and product managers about how to build security in, then you've already met with some success.