Dev Test Prod Multiple Environments for a more Secure SDLC


A small team of developers writing software for web based application services might not appreciate the need for having their code published to multiple environments. It does take some extra tooling to setup and this effort might slow down the schedule adding a few days to get that new feature out to the production go live environment.

It’s business as usual for large enterprises with different teams responsible for code, operations, networking, security, etc to have several Dev, Test, Verify, and Prod environments for a more resilient and secure software development lifecycle (SDLC).

As an extreme example of what can go wrong due to a software mistake that makes it to production this is the story of how a company with nearly $400 million in assets went bankrupt in 45-minutes because of a failed deployment.

SDLC Security Environment Release Tool Mapping

SDLC Stages – Feature Promotion Process

Software goes through a number of stages on its way from development to production. Each organization will need to adopt these concepts to their own capabilities and requirements. This drawing shows an example of how features are promoted with code going through various stages of the SDLC from development, testing, verification, integration, and deployment before finally being released into the live production environment. At each stage it is helpful to stand up a running version of the application to facilitate the functional and security testing. Some applications have SLAs that require elaborate performance and load testing to be done in a verification environment that mirrors production. Kubernetes facilitates this as we can simply create an alternate namespace using ACLs for authentication and global load balancer rules to ensure only authorized testers have access.

Microsoft Example from 2010

This is not a new concept. Here’s an article Microsoft published 10 years ago:

At a high level, the application goes through these stages as part of the development and deployment process:

  1. A developer checks some code into Team Foundation Server (TFS).
  2. TFS builds the code and runs any unit tests associated with the team project.
  3. TFS deploys the solution to the test environment.
  4. The developer team verifies and validates the solution in the test environment.
  5. The staging environment administrator performs a “what if” deployment to the staging environment, to establish whether the deployment will cause any problems.
  6. The staging environment administrator performs a live deployment to the staging environment.
  7. The solution undergoes user acceptance testing in the staging environment.
  8. The web deployment packages are manually imported into the production environment.

These stages form part of a continuous development cycle.

Microsoft drawing SDLC 2010

Oracle example 2015

2.1.1 Definition of Development Environment

An Oracle development environment is typically an installation on a single host computer (such as a Microsoft Windows desktop or laptop computer or a Linux computer). The requirements for a development environment are very different from the requirements for a production environment.

There is no need for high availability in a development environment, and the number of components and products that can be installed is typically limited to those required by the software engineer or the application that the software engineer is developing.

2.2.1 Planning for a Production Environment

An Oracle production environment is an installation where the products have been configured to deploy production-ready applications and features to your application users.

Unlike a development environment, a production system typically takes advantage of more advanced features, such as server clusters and is deployed to multiple regions.

Gigaom Key Criteria Report on Vulnerability Management

  • Vulnerability management tools scan your IT estate to help identify and mitigate security risks and weaknesses. These tools can facilitate the development of a more comprehensive vulnerability management program. Leveraging people, processes, and technologies, successful initiatives effectively identify, classify, prioritize, and remediate security threats.

    A security vulnerability is a weakness that can compromise the confidentiality, integrity, and availability (CIA) of information. Attackers are constantly looking to exploit defects in software code or insecure configurations. Vulnerabilities can exist anywhere in the software stack, from web applications and databases to infrastructure components such as load balancers, firewalls, machine and container images, operating systems, and libraries. This includes code used in the CI/CD pipeline as well as the infrastructure-as-code (IAC) that defines the compute, network, and storage infrastructure.

    Recent cybersecurity events have exposed widespread vulnerabilities involving the exploitation of zero-day malware and unknown weaknesses. Threat actors continually discover new exploitation tactics, techniques, and procedures (TTPs) to take advantage of weaknesses throughout integrated systems. Moreover, identifying breach paths is increasingly complicated due to the widespread adoption of ephemeral services.

    Vulnerability management solutions should provide end-to-end visibility of the protect-surface by aggregating both platform and application risks in a single pane of glass, while leveraging prioritized remediation based on business risk and threat context for efficiency. Containerized workloads deployed via DevOps pipelines have unique security requirements that demand a fully integrated vulnerability assessment to be automated into cloud platform services running containerized workloads.

    The path to a mature security posture starts with the ability to identify vulnerabilities in software code, third-party libraries, and at runtime. In addition, the cloud platform used to host your applications should be scanned for misconfigurations. This requires the use of policy configuration baselines, benchmarks, and compliance standards that apply to both the infrastructure and the code used to build it. As organizations implement security guardrails early in the software development lifecycle (SDLC), they can take advantage of cloud-native culture to ensure network and security tools are used throughout all phases of the SDLC.

    This GigaOm report explores the key criteria and emerging technologies that IT decision makers should evaluate when choosing a vulnerability management solution. The key criteria report, together with the GigaOm radar report that evaluates relevant products, provides a framework to help organizations assess the solutions currently available on the market and how these tools fit with their requirements.


    Here are some links to review for more info…

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s