Red Teaming

10 min read

A busy dev's guide to bulletproof app security

The security-conscious dev teams guide for bringing secure coding practices into the development lifecycle (without compromising on functionality and user experience).

CyberMnemosyne avatar

Jan 16

Developers know that application security is important. So why is integrating secure coding practices into the development lifecycle so challenging? 

Security is often seen as being a trade-off with functionality. Adding security features in the development process can seem to increase the complexity and work required to develop functionality. 

Security is also blamed for adding friction to the user experience. Leading to an app that is cumbersome and less appealing to use. 

Finally, understanding security and how to apply it in coding is a skill that developers are not normally taught as part of a computer science degree or coding course. This means secure coding is a common skills deficit in software development professionals. 

But the truth is that developers need to understand how their code can be exploited unless they guard for specific vulnerabilities. 

They should be able to check and validate inputs, understand authentication and authorisation, and have sufficient logging and reporting—so that if anything does go wrong, the issues can be dealt with.

In this article, we will explore practical strategies for integrating secure coding practices into the development lifecycle without compromising on functionality. 

We'll also delve into effective methods for gaining buy-in from senior leaders, underscoring the importance of security measures in today's digital landscape.

The essentials of implementing secure software development

How you go about implementing secure software development will depend on the nature of the organization and the information your software will handle. 

For example, security is going to be “extra” important for an organization that uses software to handle confidential medical information of its users. 

The consequences of a security breach for such a product would be more damaging than let’s say, a smaller-scale niche gaming product that stores less sensitive data and doesn’t hold private or confidential information. 

While things like your organization structure, size, and budget will impact how you implement secure software development practices, the guidelines below can be modified to suit any environment. 

Consider this your first step to launching a more security-conscious development culture.

Host a secure coding CTF for your team

Teach your team to:

  • Identify and exploit basic vulnerabilities in web applications.

  • Understand the basics of web application security risks.

  • Analyze web application traffic to detect and prevent attacks.

  • Familiarize with web application source code and identify bugs.


Security mindset: Executive support and commitment

Implementing secure software development practices starts with senior management. Specifically, they should understand the importance of product security. And would (ideally) demonstrate this commitment by integrating secure coding practices into the company’s overall information security strategy. 

This commitment should be part of every employee’s work practice, but gaining executive buy-in makes the task for developers that much easier.

Demonstrating to senior executives how software security flaws can impact the business requires a strategic approach. (Especially when you’re seeking buy-in for resources such as secure coding tools, training, or external experts who can test your code.)

Here's how to communicate this:

communicate secure coding practices
  1. Speak the board's language. Discuss vulnerabilities in terms of risk to the business, such as potential financial loss, reputational damage, legal implications, and operational disruptions.

  2. Use real-world examples. Cite recent high-profile cyber attacks and their impact on businesses. Show how vulnerabilities could similarly affect your organization.

  3. Provide a cost-benefit analysis. Show how secure coding tools can save money in the long run by preventing costly breaches. You can also focus on the value of reducing the time and resources spent on fixing future security issues. 

  4. Emphasize compliance and regulatory standards. Explain how secure coding practices help comply with industry standards and regulations, reducing the risk of legal penalties.

  5. Keep it simple. Use layman’s terms to explain vulnerabilities. Avoid overly technical language that may not resonate with non-technical leaders.

  6. Provide an implementation plan or roadmap. Present a clear, step-by-step plan for integrating secure coding practices into the development lifecycle. Extra points if you can offer a realistic timeline for implementation and expected milestones to track progress.

HTB team CTF packages for web app security

Web Application Security Level 0:

Explore fundamental concepts in web application security, including credential exposure, SQL injection, command injection and cross-site scripting (XSS).

Web Application Security Level 1:

Dive into advanced web application security topics, including insecure direct object references (IDOR), token forgery, Server-Side Request Forgery (SSRF), and more.

Web Application Security Level 2:

Challenge your expertise in web application security with complex topics like template injection, sophisticated session tampering techniques, deserialization vulnerabilities and more.


Security training and awareness

All members of the team, including developers, should understand the basics of information security—such as the terms used to describe risks, vulnerabilities, threats, controls, and so on.

Software developers need to understand common vulnerabilities, especially in the domain of their application, and the importance of security in the overall software development lifecycle.

Hack The Box Academy has several specific practical cybersecurity courses (or modules) for developers. These modules cover the basics of secure coding. From identifying bugs through code review and analysis to vulnerability scanning and patching: 

In addition to the Academy modules, there are specific Hack The Box Lab machines that cover the OWASP Top 10 web vulnerabilities as well as the most common CVEs found globally.

teach secure coding practices with HTB

Secure development lifecycle frameworks

Knowing what steps to take for stronger security throughout all stages of the software development lifecycle can be confusing. 

Fortunately, a number of secure software development standards and frameworks can help your team get started. 

An example of a public standard is NIST’s Secure Software Development Framework (SSDF). Another good framework is the Microsoft Security Development Lifecycle (SDL).

These standards follow the principle of “security by design.” Security issues are considered at all stages. Starting with gathering requirements and the subsequent design. 

If you work in the US, especially in the public sector, you will probably follow the NIST standard. In other countries, or where there is no obligation to follow NIST, the Microsoft SDL offers a comprehensive approach to the secure development lifecycle.

Do you have to implement all aspects of these frameworks? 

Of course not. But understanding them and applying relevant elements to your development project is a good start. These elements can be broken down as follows: 

Security requirements

Developers understand the principles of gathering the functional requirements for a software application. However, they may not be aware of the need to detail the security requirements at the same time. 

This will include considerations of the basic CIAAA model: confidentiality, integrity, availability, authentication, and authorization. The other security principles that are key include the principle of least privilege and defense in depth

Threat modeling

This process allows the developer to identify and assess security threats and vulnerabilities, consequent risks, and potential mitigations. 

Developers should understand the context of where and how their software will be used to fully understand the threats: medical software vs software that gives exercise tips for example.

Manage the security risk of third-party components

All software developed today will use third-party libraries, frameworks, and services. When these are incorporated into a product, they come with their own security vulnerabilities and risks. 

Knowing what packages, libraries, and components the application is using is an essential first step. 

But it is not always obvious since a component you use in development may rely on another, that relies on another; so the potential number of components used may be large. 

Tools such as GitHub’s Dependabot can help with this by automatically notifying you when an insecure package or component is being used.   

4 Secure coding practice fundamentals 

Adopting a set of secure coding guidelines is good practice. There are a number of these guidelines available including the OWASP Developer Guide. It provides a checklist for developing web applications against the top vulnerabilities detailed by OWASP each year. 

Multiple vendors will also include secure coding guidelines for their languages and frameworks. Examples of this include Microsoft’s .NET and Oracle’s Java SE guidelines.

Reviewing code for security before it is incorporated into the main repository is key. The review should be conducted with a security developer or peer before it is accepted. 

The purpose of a code review is to verify that the security and other coding guidelines have been followed and to identify any vulnerabilities. All identified issues should be corrected before the code is accepted.

ūüí°Tip: Static Analysis Security Testing (SAST) automates the process of discovering potential security vulnerabilities in code. You can find a comprehensive list of SAST tools on the OWASP website.

2. Dynamic security testing

Testing of the compiled and running version of the application for security issues should be part of the automated build/test part of the Continuous Integration/Continuous Deployment (CI/CD) process. 

This looks for issues with memory corruption, privilege issues, and the potential for attacks like SQL injection and Cross-Site Scripting, amongst others.  

3. Penetration testing

In addition to vulnerability scans, penetration tests can be carried out by internal or external security staff (or even trained developers) to probe for code security flaws. 

If possible, developers should familiarize themselves with the penetration testing and vulnerability hunting process—it will give them practical insight on how to avoid costly vulnerabilities when coding. 

Exploiting a vulnerability to get remote code execution for example, or executing a SQL injection attack to exfiltrate the contents of a database, grants developers and other team members first-hand experience of the consequences of not respecting application security.

4. Bug bounty programs

Using bug bounties is a good way of getting the security community to try and find vulnerabilities in a released, or soon-to-be-released, product. 

In an official bug bounty program, the scope can be controlled, and organizations can be used to interface and screen vulnerability reports.

There’s a chance that vulnerabilities might be disclosed by a third party, and it is always a good idea to review and respond to these disclosures. 

It is beyond the scope of this article to investigate the details of this process, but the key here is to not ignore the person bringing the vulnerability to you. The worst case is that the vulnerability is disclosed without a fix being ready for clients and users.

Develop your team’s secure software development skills 

Embedding security as a core aspect of the development process, and not an afterthought, has never been more important. 

It enables your team to build software that is not only robust and secure, but also delivers a seamless user experience.

Becoming a secure developer starts with the acknowledgment that security should be central in all parts of the software development lifecycle, starting with the principle of security by design. 

Whatever your level of experience, Hack The Box is a good way of either gaining skills in secure development or updating them through the numerous labs and training modules that highlight software vulnerabilities.

Author bio: David Glance (CyberMnemosyne), Senior Research Fellow, University of Western Australia

Dr. David Glance is a cybersecurity consultant and Adjunct Senior Research Fellow at the University of Western Australia. He has taught and carried out research in the areas of cybersecurity, privacy, and electronic health.

Dr. Glance has also worked in the finance and software industries for several years and has consulted in the areas of eHealth, cybersecurity and privacy for the OECD and WHO.

He is the author of articles and books on cybersecurity. Feel free to connect with him on LinkedIn.

Hack The Blog

The latest news and updates, direct from Hack The Box