"Security is everyone's responsibility." If you've worked in a corporate environment, I'm sure you've heard this phrase before. It usually appears as part of an annual, required security training. Then you spend the next 15 to 30 minutes learning about the dangers of opening files attached to emails and how to avoid common phishing scams. If you're a software developer, chances are you slog through these annual refreshers with mild annoyance, as quickly as possible, so you can get back to your actual work.
As advanced users of technology, we like to believe we're smart enough to recognize phishing attempts without hearing the same old warnings about not opening .exe files from someone you don't know. But, while developers may be less likely to fall for common social engineering attacks, like phishing, it doesn't mean we can't still make extremely costly security mistakes. With the constant push for faster and faster development cycles, it's easy to get so focused on solving the problem at hand, that little security issues can slip by. Even though the phrase has become a bit of a cliché, it doesn't make it any less true, "Security is everyone's responsibility". So what can you do to help foster an atmosphere of security-first development within your organization?
The "Shift-Left" trend
The "shift-left" paradigm has been making it's way through the DevOps community over the past few years. The general idea is to move security to the left on the SDLC timeline by incorporating security controls earlier in the development process. This concept has grown in popularity with the rise of CI/CD practices.
Personally, I'm not a big fan of the term for a couple of reasons. First, "shift" implies moving something from one place to another. I think the desire to implement security earlier in the process is great, but organizations shouldn't take this to mean they can replace their current security testing with some CI/CD security tools and call it a day. If you do end-of-cycle, pre-production security tests, these still need to happen. You may need to make some modifications to the process if this type of testing causes a bottleneck, but don't let this "shift left" idea lead you to believe you only need to have security checks at a single point in the development process.
The second issue I have with this concept is the way software vendors have latched onto it, as they always do, to convince you that all you need to implement the "shift left" paradigm in your organization is to integrate their tool into your development workflow. Most of these are some form of static or dynamic code analysis tools. Some of these are probably really good tools, and adding code scanning is an important part of the "shift left" philosophy, but it can't be the only thing you do.
If you truly want to make this type of shift within your organization, and you absolutely should, it takes much more than a code scanning tool. It requires not only a shift in security controls, but also in the way your organization thinks about security as a whole. Just like DevOps required a shift in the way we think about the intersection of development and operations, DevSecOps requires understanding how security fits into the overall software development process. It requires you to convince your entire team; developers, managers, product owners, designers, QA testers, that security really is their responsibility.
Creating a Security-Rich Atmosphere
If you're looking to foster this type of security-rich environment for your development team, you'll need to get buy-in across your organization. It needs to be clear to everyone, that they are a part of the security team. Likewise, your security engineers need to be made a part of the development team. This can seem like a pretty big shift in roles, but here are some things you can do to start building this type of collaborative relationship:
1. Provide secure coding training for your developers.
You need to make sure your developers understand secure coding practices. This is especially important if you're hiring a lot of junior developers. Many of these developers may have very little knowledge of secure coding practices. They may have never heard of a SQL injection or a cross-site scripting attack. They may see patterns established by your senior developers, like parameterized queries, but they may not understand the "why" behind these patterns. Sometime down the road, these developers may stray from the established patterns because they don't understand the reasons they were written that way in the first place. It's essential that all of your developers have a fundamental understanding of secure coding practices.
2. Include security engineers in your Agile teams.
I've worked at numerous clients using some form Agile. The Agile teams are usually made up of some combination of developers, architects, BAs, Scrum masters, product owners, QA testers, and graphic designers, but I have yet to work at a client where they include a security engineer as part of the Agile team. This seems like a major missed opportunity, and could prove incredibly valuable for spreading security throughout your organization. As a member of the Agile team, you have someone to answer security questions during planning, and to call out any issues they see before development work even starts on a story. This can help prevent defects and avoid rework. This also helps eliminate the imaginary wall that often separates development teams from the security team within an organization. Working together on a daily basis allows these teams to share knowledge and come up with solutions that prioritize both the business objectives and the security of the organization.
3. Identify security champions within your development teams.
If you want to spread security awareness across your teams, it's important to identify individuals who already show a passion for security on your current team. These people can be leaders in the push to foster a security-first attitude. This is especially important if you don't have the ability to insert security engineers into your Agile teams. Provide additional training to these developers, and they'll be able to take on some of the security focus during planning. They can also help mentor more junior developers on secure coding practices.
4. Include security scenarios in your automated testing.
If you're doing automated QA testing, consider including security scenarios in these tests. Test input fields for SQL injections and ensure the proper errors are returned, for example. This can be especially helpful for testing common security vulnerabilities in fast-moving continuous deployment projects. This type of automated testing shouldn't take the place of thorough manual testing or penetration tests, but it can provide a good solution for preventing regressions in your code base. If you've included a security engineer on your Agile team, this is a great time for them to collaborate with your automated QA team to figure out which scenarios can be tested this way.
5. Require a security-specific code review
This is a big one, and probably my favorite tip for increasing security consciousness within a development team. It does introduce another step into the development workflow, and it may slow things down a little bit, but the benefits can be huge. The idea is that when a developer has a change that's ready to deploy, their code goes through the normal peer review process. This initial review is for code quality; ensuring that best practices and established patterns have been followed. Once this is approved, a second review is required, this review focuses specifically on security issues that might be caused by the change. This reviewer is less worried about the code, and more about the security implications. What is the risk level of the changes made? Is there any PII involved in the change? Are display changes properly scoped so they will only be seen by authorized users? Is any new data being transmitted to a third-party partner? Are any new dependencies being added to the project? Have unit tests been written that thoroughly cover any areas of concern? It may help to identify the primary questions that need to be asked and provide a checklist for reviewers to use. The great thing about this type of review is that it not only helps to catch security bugs before they're released in productions, but it also helps to emphasis to your developers how seriously you take code security, and it provides great learning opportunities to your team. Your developers are forced to consider security during development, the reviewer is required to think through the potential security implications of each change, and when an issue is pointed out, it's an opportunity for the reviewer to share knowledge with the developer.
6. Integrate automated tools into the development workflow.
In order to ensure the best security for your applications, you'll need to include some automated tools in your development process. These may include things like static code analysis tools, dynamic code analysis tools, dependency scans, etc. There are both commercial and open-source tools available in each category, and which tools you need will be determined by your own organization's needs. These tools provide additional layers of security to your development pipeline, but they shouldn't be relied on too heavily. I included this tip last for a reason. No matter how many automated tools you throw in the pipeline, they can never compete with the benefits gained by fostering a truly security-focused atmosphere within your organization.
Shifting a development team to a security-first attitude is no small task. There will undoubtedly be push-back, but as developers, we play a huge role in an organization's digital footprint, and we have a responsibility to ensure that we've done all we can to limit the risk involved in any changes we make. At the same time, our organization has a responsibility to ensure that their developers have the tools and training they need to write secure code. Implementing the tips above is a good starting point for making the shift to a truly security-focused development team.
Top comments (0)