Software Development and Full-Stack Engineering Risk Assessment: Malware, Access and Recovery Controls

This assessment shows how a product team building a web application with a browser front end, a server back end and a managed database can find, rate and control the risks that matter most. Eight hazards were selected because they are plausible in everyday engineering work, from malware and phishing to third-party code, misconfiguration, weak logging and poor recovery. Each is scored before controls and again after existing and added controls. Personal data copied into test environments scores highest before controls, and it falls to Medium once the proposed controls are in place. Most other risks also fall to Medium or Low. The first actions are multi-factor sign in for all repository and cloud accounts, removal of standing production access, masking of test data and a tested database restore. The scores are teaching examples that illustrate method, not measurements of any real system.

Scope

This assessment covers the development, build, release and operation of a single web application, including source code, repositories, build pipelines, cloud hosting, the managed database and the logging used to run it. It looks at risks to the confidentiality, integrity and availability of data and services. Jurisdiction, team size, hosting arrangements and data types are assumptions made for teaching, and mobile apps and hardware are not covered.

Context

The team has six engineers, a product owner and a part-time operations lead. Code is kept in a shared version control system, built by an automated pipeline and deployed to cloud containers. The application stores customer account details and order history in a managed relational database. Engineers use laptops with administrative rights and draw on open-source libraries and hosted services. Each risk is scored before controls to show its natural level, then again after existing controls and the additional controls the team should add.

Objectives, assets and stakeholders

The objective is to ship features safely and frequently while keeping customer data confidential, code and data accurate and the service available to users. Assets in scope are source code, build and deployment pipelines, cloud accounts and secrets, the production database and its backups, customer personal data, logs and the reputation of the product. Stakeholders include engineers, the product owner, operations staff, customers whose data is held, the privacy lead, suppliers of hosted services and open-source maintainers, and senior management. Every risk has one owner role. The engineering manager keeps the register current and reports to leadership each quarter, and privacy and security specialists review anything that touches personal data or regulated duties.

Each risk is rated on two five-point scales. Likelihood runs from Rare to Almost certain and impact runs from Insignificant to Severe, with the scale defined in the team handbook. Multiplying the two gives a score from 1 to 25 that falls into one of four bands: Low from 1 to 4, Medium from 5 to 9, High from 10 to 16 and Critical from 17 to 25. Inherent risk is the score before any controls, judged as if only basic practice were in place. Residual risk is the score after existing controls and additional controls are working, and it must never be higher than inherent. Impact considers loss of confidentiality, integrity and availability, legal exposure, customer harm and recovery time. Critical risks need a named owner and a dated plan agreed with the engineering manager within days. High risks need an owner and a plan within the target timeframe, Medium risks need routine controls and monitoring, and Low risks are accepted and watched. Ratings are challenged in a short review where a second engineer and the operations lead test the evidence for each control, and a rating is lowered only when that evidence exists. Any indicator reaching its threshold triggers a fresh rating.

Contingency arrangements

If a serious event occurs, such as confirmed malware on a build machine, a leaked credential or a data exposure, the engineering manager declares an incident and assigns a lead. The on-call engineer isolates affected accounts, rotates secrets and pauses deployments. Logs are preserved, and the operations lead restores service from the latest tested backup. The privacy lead decides whether regulators or affected customers must be told, using specialist advice for the relevant jurisdiction. A post-incident review then updates the register and the controls.

Conclusion

Reliable software depends on a few steady habits: strong sign in for every account, least privilege, reviewed dependencies, tested recovery and logs that can answer questions after an event. The highest scores sit with personal data in test environments, supply chain exposure and malware reaching engineering machines, and each has controls that bring residual risk down. Treat the register as a living record, review it on the stated cycle, and seek qualified security, privacy and legal advice for any real system.