Comptia Security+, Security, Technology

Security+ Course – 3.5. Secure Staging and Development

1. Software Staging and Release

Deploying code without processes (the wrong way to do it)

  • Surprises end users
  • Introduces security flaws
  • Causes operational disruptions
  • Increases the difficulty of rolling back flawed code

Stage 1 – Development Environment
Allows developers to develop and modify code

Stage 2 – Test Environment
Facilitates human and automated testing

Stage 3 – Staging Environment
Prepares the code for release to production in a simulated environment. Load testing occurs at this stage.

Stage 4 – Production Environment
Provides live services to end users

Important issues in these stages

  1. Sensitive data: this should be tightly controlled or prohibited in non-production environments. EG: use test data
  2. Code deployment: this should be done by someone other than a developer. EG: a release management team.



2. Software Risk Assessment and Mitigation

Risk Analysis identifies risk

Risk Mitigation reduces their likelihood and impact

Software Development Lifecycles (SLDC)

In Software Development security must be integrated from the very start. It is not something that can be added in later. Security should be integrated with the Software Development Lifecycle (SLDC). SLDCs include:

  • Waterfall
  • Agile
  • Spiral

Security must be integrated at all stages – Design, development, testing and deployment.

Mitigate Software Risks

Some ways to mitigate software risks include:

  • Perform input validation on user input
  • Encrypt sensitive data so that if a database does get compromised the data is encrypted
  • Enforce the principle of least privilege
  • Test all code prior to deployment


This is a test environment where developers can run their code without it having access to production resources. Sandboxes work hand in hand with code repositories. A developer may test a copy of code from a repository in a sandbox, then once finished testing they put it back in the repository.



3. Security Baselines and Integrity Measurement

A baseline is a minimum or a starting point used for comparisons.

Deviations: these are changes from the baseline

Integrity Management: this tracks changes made to code after deployment, noting unexpected changes

Leave a Reply

Your email address will not be published. Required fields are marked *