Secure Software Development Practices

Secure Software Development Practices
< /> SECURE DEVELOPMENT OWASP Top 10 (common vulnerabilities): A01 Broken Access Control A02 Cryptographic Failures A03 Injection (SQL, XSS, etc.) A04 Insecure Design A05 Security Misconfiguration A06 Vulnerable Components A07 Auth Failures A08 Software Integrity Failures Shift-left: build security in from design never store secrets in source code

Learn OWASP Top 10 vulnerabilities, how to shift security left in the development lifecycle, and best practices for secrets management and dependency security.

Secure Software Development Practices

Security must be built into software from the start — not bolted on at the end. The cost of fixing a vulnerability in production is 30x higher than catching it during design.

Shift Left: Security at Every Stage

SECURE SDLC — security activities at each phase REQUIREMENTS Define security requirements Threat modelling DESIGN Secure architecture Least privilege Design review DEVELOPMENT Secure coding guidelines, SAST Code review TESTING SAST, DAST, SCA Pen testing Security testing DEPLOYMENT Secrets management Infra hardening Config review OPERATIONS Monitoring, patching Vulnerability mgmt Continuous security Cost to fix a bug: $100 in Requirements → $1,500 in Testing → $10,000+ in Production

The OWASP Top 10

The Open Web Application Security Project (OWASP) publishes the most common and critical web application vulnerabilities. Every developer should know these:
RankVulnerabilitySimple Example
A01Broken Access ControlUser can access another user’s data by changing the URL
A02Cryptographic FailuresStoring passwords in plain text; using HTTP not HTTPS
A03InjectionSQL injection: '; DROP TABLE users;-- in a login field
A04Insecure DesignNo rate limiting on login — allows unlimited password guesses
A05Security MisconfigurationDefault admin credentials left enabled
A06Vulnerable ComponentsUsing a library with a known CVE
A07Auth FailuresSession tokens that never expire
A08Integrity FailuresDeploying code without verifying its source
A09Logging FailuresNo audit trail of who accessed what data
A10SSRFApp fetches URLs from user input without validation

SQL Injection — Visual Example

SQL INJECTION — how user input becomes a database command INTENDED QUERY: SELECT * FROM users WHERE user=’alice’ AND pass=’secret’ ATTACKER INPUTS: ‘ OR ‘1’=’1 RESULTING QUERY: SELECT * FROM users WHERE user=” OR ‘1’=’1′ AND pass=” ⟹ ‘1’=’1′ is always TRUE — returns ALL users
⛔ Important
Never concatenate user input directly into SQL queries or shell commands. Always use parameterised queries (prepared statements). This single practice prevents the most common class of critical web application vulnerabilities.

Secrets Management

API keys, database passwords, and credentials must never be stored in code:
⚠ Warning
Thousands of AWS keys, database passwords, and API secrets are accidentally committed to public GitHub repositories every day. Once a secret is in version control history, it must be considered permanently compromised — even if you delete it, it remains in git history. Use environment variables or a secrets manager (HashiCorp Vault, AWS Secrets Manager) instead.

Dependency Security (SCA)

Modern applications rely on hundreds of third-party libraries. Each one may contain vulnerabilities:
  • Run Software Composition Analysis (SCA) tools to detect vulnerable dependencies
  • Subscribe to vulnerability notifications for libraries you use
  • Update dependencies regularly — not just when a feature is needed
Building or buying software for your business?
One vulnerable app or misconfigured server can expose everything behind it. Mobile Techs IT Service helps Gold Coast businesses keep their software stack secure — vetting and hardening business applications, keeping systems and dependencies patched, locking down default configurations, and securing the websites and servers you rely on. Home users welcome too — on-site or remote, anywhere in Australia.