Why secure-by-design should be your default approach

Explore how taking a proactive, structured approach to security early in a project can significantly reduce risk, improve team velocity and prevent expensive rework later.

By Jon Bennett, Lead Developer @ Steer73
Two women engaged in a discussion while working on their computers, collaborating on a secure by design project

It hardly needs saying that security is a critical consideration for any business system. With the rise in cyber attacks, the emergence of ransomware-as-a-service and the potentially catastrophic—often business-ending—impact of a breach, you don’t need to be a high-profile target to be at risk. Today, businesses of all sizes must meet increasingly stringent security standards.

When building systems, security isn’t something to bolt on at the end. It’s a mindset and discipline that needs to be embedded from the very first planning session.

In this article, we explore how taking a proactive, structured approach to security early in a project can significantly reduce risk, improve team velocity and prevent expensive rework later.

From aligning stakeholders on security requirements and establishing a secure architecture in the cloud, to leveraging integrated tooling and building a culture of peer review and transparency, here are five practices that aren’t just technical checklists – they’re the foundation of resilient software delivery.

 

1. Establishing clear security requirements from the start

Before beginning any development work, establish a clear understanding of the solution’s security objectives by identifying the stakeholders’ security requirements.

Factors to consider include:

  • Are there existing security measures that need integration into the development lifecycle (e.g. can’t be publicly accessible)?
  • Are there compliance requirements you must adhere to (e.g., data residency, encryption standards)?
  • Which repository will be used and who will host it?
  • Which system will be used to track work items and who will host it?
  • What validations should be performed when deploying software? For example, are there stakeholders who must sign off on each deployment?

Identifying these requirements early reduces the risk of unexpected surprises that can derail progress or cause scope creep.

Formalising these requirements into technical architecture documentation early—and sharing it with stakeholders—creates a clear, mutually agreed-upon reference that proves invaluable when questions or disputes arise.

 

2. Setting up a secure architecture

Investing a little extra time at the project’s outset to establish a secure architecture helps avoid costly retrofits later. As an example, here are some key practices we have incorporated into many of our Azure projects.

Centralised authentication with Entra
Implement Entra authentication from the outset to manage user identities and resource access. Disabling key-based access wherever possible minimises the risk of compromised credentials.

Early integration of key services
Integrate services like Azure App Configuration and Azure Key Vault into your application’s startup process. This ensures that configuration settings and sensitive information such as secrets, keys and certificates are managed securely from day one.

User group-based access control
Assign access to resources using user groups rather than individual users. This method is quicker and easier to set up, provides better transparency and simplifies user onboarding and offboarding processes.

Infrastructure as Code for consistency
Leverage Infrastructure as Code (IaC) to define and manage your environment securely. This approach ensures that security configurations remain consistent, are version-controlled and can be audited regularly. If permissions are set up appropriately, this also ensures any changes to the environment are subject to peer review.

 

3. Leverage all available tools

While a strong understanding of security best practices is essential, developers often cannot match the breadth of expertise available from dedicated security firms.

Specialist knowledge can be readily accessed, albeit at an additional cost, through a range of integrated tools.

SAST
Static application security testing (SAST) involves reviewing the source code of the solution to look for known sources of vulnerabilities (e.g. SQL injection). Integrations can be set up to prevent code merges containing such issues.

Examples of popular SAST tools include Snyk, GitLab and Mend.

DAST
Dynamic application security testing (DAST) involves probing the application itself for known vulnerabilities (e.g. header vulnerabilities, CSRF). After deploying to a staging environment, such tools can probe applications autonomously and provide detailed reporting on their findings.

Examples of popular DAST tools include OWASP ZAP and Tenable Web App Scanning.

SCA
Software composition analysis (SCA) tools scan the dependencies of a project and compare them with lists of known vulnerabilities. Some of these can also optionally update the dependencies to known safe versions.

Examples of popular SCA tools include Snyk, Mend and GitHub Advanced Security.

Secret scanning
Accidentally checking a secret into source control can be a headache: even after removing the secret, it will persist in source history, so cycling keys is usually recommended.

Secret scanning tools reduce the risk by scanning code and detecting potential secrets before they’re committed.

Popular secret scanning tools include Github Advanced Security for Azure DevOps and SpectralOps.

 

4. Collaborative oversight and transparency

Every code change should be peer-reviewed and every new feature demonstrated internally. This process not only catches issues early but builds trust and fosters continuous improvement. For longer projects, it’s also a useful way to keep track on progress.

Enhanced code quality and security:
By subjecting each code change to thorough peer reviews, teams can detect security vulnerabilities, bugs and coding standards issues before they become a larger problem. Note that although peer reviews significantly reduce risk, they are not a substitute for dedicated QA..

Regular demos for stakeholder alignment:
Regular demos allow team members and stakeholders to see progress in real time. These sessions encourage open feedback, which can lead to early adjustments in direction, clarify expectations and ensure that the product aligns with business goals.

Knowledge sharing and continuous improvement:
Peer reviews and demos lead to knowledge sharing among the wider team. They provide opportunities for less experienced developers to learn from seasoned team members, as well as demonstrate their expertise to their peers. Over time, this culture of collaboration leads to a more capable and adaptable team.

Increased transparency and accountability:
Transparent processes, from code reviews to regular demos, help build trust across the organisation. Everyone is aware of what is being developed and how decisions are made, which reduces silos and encourages accountability. A tight feedback loop also aids in professional development for team members.

Cultural fit:
The above can only work in an environment free of blame and ego. When the focus is on collective ownership and improvement, team members are more willing to share insights, ask questions and offer constructive feedback (as well as receive feedback).

 

5. Logging and monitoring

Even with diligent design and development, issues can still arise over time. When setting up a system, it’s important to have a mature logging strategy in place, so you can respond quickly.

Some key factors to consider include the following:

Real-time visibility:
Implement continuous logging and monitoring to gain real-time insights into system behaviour, enabling quick detection of unusual activity and potential breaches. Azure provides a lot of this functionality with resource telemetry and straightforward integrations with Application Insights.

Proactive alerting:
Set up alerts to notify your team immediately when anomalies or suspicious patterns occur. Proactive alerting helps reduce the mean time to detection and resolution of issues. Tools like Microsoft Defender for Azure can help provide this functionality at additional cost.

Compliance and auditing:
Regular logging and monitoring support compliance with regulatory requirements by maintaining an audit trail of system activities. This ensures that you can demonstrate adherence to security standards during audits. Audits can also help with forensics when assessing the impact of an incident.

Centralised log management:
Use centralised log management solutions to consolidate logs from various sources. This makes it easier to correlate events, analyse trends and generate actionable insights. Tools like Azure’s Application Insights provide a comprehensive suite of capabilities. It’s also important to be aware of the volume of data you’ll be capturing and what retention period is required, as both have a cost impact. Unrestrained log growth from a recurring error (for example) can be a source of sudden unexpected cost.

Continuous improvement:
Analysing logs over time helps identify recurring issues and potential areas for improvement in your security posture. This feedback loop enables ongoing refinement of your security practices.

Security isn’t a single feature or a one-time checklist—it’s a mindset that should guide every phase of software development. By embedding secure practices from day one, teams not only reduce risk but also build faster, more confidently and with fewer costly surprises down the line. As threats continue to evolve, adopting a secure-by-design approach isn’t just best practice—it’s essential.

As always, if you want help building, launching or managing secure software, Steer73 are here to help.

Subscribe to our newsletter

For regular insights into UX, product management, innovation and technology, sign up to our newsletter.

Get In Touch