SecuresoftwaredevelopmentinEthiopia:gettingitrightbeforelaunch
Having an app or system built? Security is far cheaper before launch than after. What secure development means, and what to demand from any developer.
Secure software development means building security into an application as it is written rather than testing for it afterwards: proper authentication and access control, safe handling of payment and personal data, reviewed dependencies, and hardened deployment. Fixing a flaw during development costs a fraction of fixing it after launch.
Last reviewed
Why this matters most before you launch
The economics are lopsided and they are the whole argument. A missing authorisation check found while the feature is being written is a ten-minute fix. The same check found after launch is an incident: customer data has already been exposed, you have a notification obligation under Proclamation 1321/2024, and the fix now has to be shipped to a live system with real users on it.
This is the most common way Ethiopian businesses get hurt, and it is almost always a build-time decision that nobody revisited. Not a firewall someone failed to buy - a login that could be bypassed, an upload that could be made to execute, an API returning more than the screen displayed.
What to ask any developer for
This section is useful whether or not you work with us. If you are commissioning software from anyone, these are reasonable things to require in writing, and a competent developer will not object to any of them.
- Individual user accounts with role-based permissions, and multi-factor authentication available on administrative accounts.
- Authorisation checked on the server for every request - not hidden menu items, which stop nobody.
- Passwords stored using a modern password hashing algorithm, never encrypted and never in plain text.
- Personal and payment data encrypted in transit and at rest, with a written statement of what is stored and for how long.
- Payment integrations that verify callbacks and amounts server-side, so a client-side value cannot be tampered with.
- Dependencies pinned, tracked and updated, with a documented process for responding to a vulnerability in one.
- Logging of authentication events and administrative actions, retained long enough to investigate an incident.
- Automated backups, and at least one documented restore that somebody has actually performed.
- Secrets in environment configuration rather than in the source repository.
Ask a prospective developer: "how do you make sure one customer cannot see another customer's data?"
Broken access control is the most common serious flaw in the applications we assess, and the answer to that question separates people who have thought about it from people who will discover it in production. A good answer describes server-side ownership checks on every request. A bad one describes the user interface.
How we build
Security is not a phase at the end here; it is distributed through the work:
- Threat modelling at designBefore code: what data does this hold, who must never see it, and what happens if each component is compromised. An hour here removes whole categories of flaw.
- Secure defaults in the frameworkAuthentication, authorisation, input validation and output encoding handled by the framework rather than reimplemented per feature. Most vulnerabilities are hand-rolled versions of solved problems.
- Code review with security in scopeEvery change reviewed by a second engineer, with access control and data handling explicitly on the checklist rather than assumed.
- Dependency and vulnerability scanning in CIAutomated, on every build, so a known vulnerable package fails the pipeline instead of shipping quietly.
- Hardened deploymentLeast-privilege service accounts, secrets outside the repository, security headers, TLS configured properly, admin interfaces not exposed to the public internet.
- A test before launchThe application assessed as an attacker would see it, and the findings fixed before real customer data goes in.
If it is already built
Most people find this page after the fact, with a system already live and a growing suspicion that nobody checked. That is a normal position to be in and it is recoverable.
The sequence is: assess what is actually exposed, fix what carries real consequence, and then decide whether the codebase is worth continuing with. Sometimes the honest answer is that a rewrite of one component is cheaper than defending it indefinitely - and we will tell you that even though the smaller engagement is the easier sale.
Questions people ask
Building something that holds customer data?
Bring us in at design rather than after launch. An hour of threat modelling at the start removes work that would otherwise arrive as an incident.