How Devs Can Improve Security (Part One)

To understand the current and future state of the cybersecurity landscape, we spoke to and received written responses from 50 security professionals. We asked them, “What suggestions do you have for developers to improve the security of their applications and data?”

This is the first in a series of three articles.

SDLC/Shift Left

  • Follow secure SDLC practices. Automate testing, continuously test any change, and perform end-to-end testing of special production components. Understand the security implications of changes. Segregate business functions from security controls. Ensure every business function is covered by a security control.
  • Developers can improve the security of their work by addressing security concerns at the code-level. This includes making the code itself more robust, modular, and mature. In addition, always remember that there is no such thing as a “general” approach to protecting critical systems and data. Your plan needs to address the actual requirements that apply to your organization, such as compliance with specific laws and regulations, contractual requirements, and the threat landscape that applies to your industry.
  • Developers need to change the way they design their products. Security should be prioritized from the start of any project and embedded into the architecture.  Security features should always be enabled in frameworks and platforms, despite the higher costs of implementation. 
  • Shift security left into the engineering workflow, do security simulation, and secure coding training. Secure coding training providers like Hacksplaining.
  • We spend a lot of time training on developer coding techniques, but not as much on training secure software development. One methodology worth exploring is the secure software development lifecycle (SDLC) process. It integrates penetration testing, code review, and architecture analysis. Developers should invest time in taking secure development courses and use security testing tools as part of their development processes. Be proactive about patching code as it is developed versus being reactive and fixing it after deployment.
  • Incorporate security into the design of your product from the beginning and constantly iterate throughout the process. Test to learn about vulnerabilities before release. Perform internal and external security testing.
  • We see developers playing a key role in advancing security with a “shift left” mentality, which means integrating security checks as early as possible in the software development lifecycle (SDLC). If your security and compliance teams aren’t getting involved earlier in the SLDC, find them, and get them involved. Use DevSecOps tooling to give them a voice early in the process using the same tools and languages developers are using. Embrace the security team leveraging automation post-deployment and help them get it right. 
  • Start planning for security as early as possible. Try to include design reviews and limit data collection to the minimum amount necessary. I also recommend relying on proven common standards and frameworks, instead of building something new whenever possible. Starting something from the ground-up can be exciting, but it can also expose you to vulnerabilities and blind spots you hadn’t considered. Common standards can help reduce development cycles. 
  • Shift left. Harden applications from the “get-go.” Deploy homegrown applications in a secure way. Take a data-centric approach, so when you move data out, you move it in a protected state. Look at everything holistically.
  • Good software is secure, and secure software is good software. Think about security like you do any aspect of quality. You wouldn’t wait until the moment before your final production deployment to look for functional bugs, so why would you do that for security vulnerabilities? Include security from the earliest possible point in the software development lifecycle. It is much easier and cheaper to adjust code while it’s still under development than to retroactively include security fixes.


  • Developers need to be thinking about source code audits. Putting quality assurance programs in place will become a table stakes issue. You will start losing business, especially in regulated industries. You could also be forced by regulators to do vendor management.
  • Every line of code is at risk. If you are not mindful of what you write using elevated privilege to access your code, that loophole can be exploited. You can put the entire enterprise at risk. Every line of code needs to be evaluated and audited. Don’t use elevated privilege unless absolutely necessary.
  • Maintaining a secure development lifecycle (SDLC) is critical to improving the security of web applications. A crucial part of any proper SDLC is performing static application security tests (SAST) prior to deployment to your production environment. This helps identify vulnerabilities within the application before going live, giving the developer the opportunity to mitigate potential issues ahead of launching or updating.
  • It would be great if every developer was trained on secure coding best practices, but we know this is unrealistic. The best thing an organization can do is empower developers to scale and self-serve. This means introducing automated capabilities, such as vulnerability scanning of code at the time of code commits and alerting on potential vulnerabilities developers can address right away. When done well, this is very empowering to developers. The other side of the same coin is preparing for gaps in automation and running public bug bounty programs as well as building internal red teams. While some of these measures are proactive and others are reactive, a mature security team will use both approaches to empower developers and minimize risks.

Education/Best Practices

  • Getting security right starts with awareness. Be aware of the threat landscape. Educate on challenges. Employ better practices.

    Employ tools that provide security insights earlier in the development lifecycle and eliminate undesired events that may end up in production.

    Use the right tools to enhance the delivery pipeline, and don’t slow it down. Look for tools that give you distilled and crystallized insight rather than ones that provide irrelevant data or issues.

  • Developers more than ever need to understand and define upstream and downstream clients of the application service. Then, they need to fully isolate those interactions, so malicious actors can’t gain access. Open source is great, but developers need to vet the software being used in applications and make sure each new update is scanned for vulnerabilities.
  • Follow best practices, and use the facilities of the operating systems and service providers you have chosen. Don’t do it yourself! Security needs to be the first thing you think of, not an after-thought.
  • Think about data at rest. What is the sensitivity of the data? Does it have PII or cryptographic information? Are you taking steps to ensure it’s not exposed? As a programmer, you must think about securing the data. Am I minimizing attack surface areas? Am I staying up to date on protocols?
  • Software developers should be required to be trained in cybersecurity. The ones that do, learn how to break software applications. They become amazing penetration testers. If more developers understand how to build secure applications and fundamentally protect data, we can reduce the crazy cycle of build-test-deploy-fix as exploits are reported.
  • You should employ more strategic approaches to identify and fix problems. This approach should be driven by organizational policies and engineering processes. Get the right training based on the types of applications you are developing. Think about what cybersecurity skills are needed based on the applications they are working on? Establish a relationship between what developers are working on and the skills they need.
  • The developers should start somewhere. It does not really matter where. If you can do security training, do it. If you can set up a simple code quality scanner like FindBugs, do it. Start with any small step you can take now. Taking steps creates awareness and forces you and the people around you to think about security.

This is the first of three articles that share what IT professionals think developers could be doing to improve the security of their code and applications. Take a look at Part 2 and Part 3.

Here’s who shared their insights:

This UrIoTNews article is syndicated fromDzone