1. Environment
   1. Informal Coding:
      1. The programmer continuously performs these actions until a single working product is produced:
         1. Write
         2. Test
         3. Debug
      2. Flaws:
         1. Lack of controls
         2. Potential security flaws
         3. No formal testing process
   2. Structured software development avoids the flaws of informal coding with distinct environments for each stage of the code release process:
      1. Development Environment
         1. Where the code is created.
         2. Examples
            1. Eclipse
            2. Notepad++
            3. VS Code
            4. Sublime
      2. Test Environment
         1. Where the code is tested.
         2. Examples
            1. Virtualized Environments
            2. Containerized Environments
            3. Vagrant
            4. Docker
            5. Actual Devices
      3. Staging Environment
         1. Pre-production (once all tests have been passed).
         2. Staging is designed to replicate the production environment as closely as possible, to give developers and testers the chance to closely simulate how the code will work when it is released to production.
         3. Load testing occurs in pre-production environments.
      4. Production Environment
         1. When the code is cleared for release, it moves into the production environment, where it is known as live code and released to end users.
   3. Security Concerns
      1. Development environments have weak access controls and weak security.
      2. A single person should not move code (or any sensitive information) between environments. Controls should be in place to securely move code between environments, using a management team or version control process to verify its authenticity.
2. Sandboxing
   1. Development and testing environments where programmers can work with code to modify and test it without having access to production resources.
   2. Sandboxes provide isolation between host and hosted environments.
3. Secure Baseline
   1. The purpose of a baseline is to provide a reference point from which changes in the measured object's attributes, know as deviations, may be observed.
   2. In software development, baselines are used in two ways:
      1. Version Control
         1. Baselines are used during the active development process to track changes made.
         2. Deviations may represent failed updates or unauthorized changes.
      2. Integrity Measurement
         1. Baselines may be used during the active phase of the product life cycle to ensure the code has not been tampered with or otherwise changed.