Merge branch 'main' into azure-log-alert

adr/007-software-bill-of-materials.md

@@ -4,11 +4,7 @@ Date: 2022-12-07
 
 ## Decision
 
-In the context of generating a secure modern application,
-facing the need to monitor application dependencies and generate a
-reliable SBOM, we decided to use the [CycloneDX Gradle Plugin](https://github.com/CycloneDX/cyclonedx-gradle-plugin#usage)
-and against the use of Anchore/Syft or Snyk FOSSID for SBOM generation at release of a version build,
-accepting that an SBOM needs to be generated during the CI/CD process
+In the context of generating a secure modern application, facing the need to monitor application dependencies and generate a reliable SBOM, we decided to use the [CycloneDX Gradle Plugin](https://github.com/CycloneDX/cyclonedx-gradle-plugin#usage) and we chose not to use [Anchore/Syft](https://github.com/anchore/syft#supported-ecosystems) or Snyk FOSSID for a smoother read.
 
 
 ## Status
@@ -17,14 +13,42 @@ Accepted.
 
 ## Context
 
-An SBOM (Software Bill of Materials) is a machine-readable inventory
-document (that will be generated with each release build) that captures
-all the software components and dependencies, info on those components,
-and hierarchical relationships.
-- CycloneDX plugin for gradle can be automated for use with existing CI/CD pipeline
-- CycloneDX can work with [Anchore/Syft](https://github.com/anchore/syft#supported-ecosystems) for format conversion
-- CycloneDX can work with [Anchore/Grype](https://github.com/anchore/grype#recommended) for vulnerability scanning
-- CycloneDX is an accepted standard for the industry
+An SBOM (a Software Bill of Materials) is a machine-readable inventory document (that will be generated with each release build) that captures all the software components and dependencies, info on those components, and hierarchical relationships.
+
+## Impact
+
+### Positive
+- **Automation in CI/CD:** The CycloneDX Gradle Plugin can seamlessly integrate SBOM generation into the CI/CD pipeline, ensuring the SBOM is always up to date with each release. 
+
+
+- **Industry Standard:** CycloneDX is widely accepted in the industry, ensuring compatibility with other tools and making compliance with security standards easier. 
+
+
+- **Vulnerability Scanning:** With the ability to integrate with tools like [Anchore/Grype](https://github.com/anchore/grype#recommended), one can easily add vulnerability scanning to the process. 
+
+
+- **Format Conversion:** supports integration with Anchore/Syft for SBOM format conversion, providing flexibility to meet different ecosystem requirements.
+
+
+
+### Negative
+
+- **Tooling Overhead:** Maintaining additional tooling for SBOM generation (CycloneDX and optional tools like Grype and Syft) could increase the overhead for the project and team, in terms of learning and managing multiple components. 
+
+
+- **Build Time Impact:** The generation of an SBOM might increase the build time, especially as the project grows in complexity.
+
+
+### Risks
+
+- **Compliance Dependence:** Relying on CycloneDX as the primary tool for SBOM generation means that any bugs, limitations, or updates to the plugin can impact your compliance process. 
+
+
+- **Tool Maintenance:** Keeping CycloneDX and its integration with vulnerability scanning tools like Grype up to date _could_ require ongoing maintenance efforts to ensure compatibility and security.
+
+
+- **Integration with Other Tools:** Future security or compliance needs _could_ require integration with other SBOM standards or tools not supported by CycloneDX, limiting flexibility. 
+
 
 ### Related Issues
 

adr/008-load-testing.md

@@ -4,29 +4,49 @@ Date: 2022-12-21
 
 ## Decision
 
-In the context of maintaining quality of service,
-facing the need to consistently monitor and address performance concerns
+In the context of maintaining quality of service and the need to consistently monitor and address performance concerns, we decided to use [Locust.io](https://locust.io/) instead of [Artillery.io](https://www.artillery.io/) or [JMeter](https://jmeter.apache.org/) for load testing. We accept that performance testing needs to be completed as part of the definition of done.
 
-we decided to use the [Locust.io](https://locust.io/)
-and against the use of [Artillery.io](https://www.artillery.io/)
-or [JMeter](https://jmeter.apache.org/)
-
-for load testing, accepting that performance testing needs to completed
-as a part of the definition of done.
 
 ## Status
 
 Accepted.
 
 ## Context
 
-Load Testing assists in determining the performance of a system under
+Load Testing will assist in determining the performance of a system under
 real-life load conditions, both normal and extreme.
- - Locust.io is free, open-source, scalable
- - Tests written in Python
- - Works with gRPC servers
- - Easy to use UI
- - Simple setup and task configuration
+
+## Impact
+
+### Positive
+
+- **Scalability:** Locust.io is highly scalable and can simulate millions of users, making it ideal for both small-scale and large-scale load tests. 
+
+
+- **Python-Based:** Writing tests in Python allows for flexibility and ease of use, especially for teams already familiar with the language. 
+
+
+- **Cost Efficiency:** Locust.io is open-source, and doesn’t require licensing fees, which can reduce the overall cost of performance testing.
+
+
+### Negative
+
+- **Limited Features:** Compared to more feature-rich tools, Locust.io might lack advanced performance monitoring or detailed reporting features. 
+
+
+- **Manual Script Writing:** Test scripts need to be manually written, which could be more time-consuming compared to GUI-based test creation offered by tools like JMeter or Artillery.io.
+
+
+### Risks
+
+- **Scalability Complexity:** While Locust.io is scalable, setting up distributed testing across multiple machines can introduce complexity, especially for teams with limited experience in handling distributed systems. 
+
+
+- **Tool Ecosystem:** If future testing needs expand beyond Locust.io's capabilities, there may be a need to switch or integrate with other tools, leading to additional complexity or costs. 
+
+
+- **Resource Usage:** Running large-scale tests using Locust.io may require significant system resources, which could impact cost and infrastructure planning.
+
 
 ### Related Issues
 

adr/009-docker.md

@@ -6,19 +6,54 @@ Date: 2022-01-04
 
 We will use [Docker](https://docs.docker.com/get-started/overview/) for containerization of our application.
 
+
 ## Status
 
 Accepted.
 
 ## Context
 
 Docker is an open platform for developing, shipping, and running applications. Docker provides the ability to package and run an application in a loosely isolated environment. Some benefits of using Docker:
-- Develop your application and its supporting components using containers.
-- The container becomes the unit for distributing and testing your application.
-- When you’re ready, deploy your application into your production environment, as a container or an orchestrated service.
-- Allows for responsive deployment and scaling.
 
-[Reference](https://docs.docker.com/get-started/overview/)
+
+## Impact
+
+### Positive
+
+- **Compatibility:** Docker containers can run consistently across various environments (development, testing, production), reducing compatibility issues and making it easier to move applications between different environments.
+
+
+- **Isolation:** Each container runs in its own isolated environment, which minimizes conflicts between applications and simplifies dependency management.
+
+
+- **Scalability:** Docker supports scaling applications easily through container orchestration tools like Kubernetes, allowing for better resource management and load handling.
+
+
+- **Rapid Development:** Containers can be quickly built, tested, and deployed, accelerating the development cycle and improving productivity.
+
+
+- **Ecosystem and Community:** Docker has a large and active community, providing a wealth of resources, tools, and best practices that can help in troubleshooting and optimization.
+
+
+### Negative
+
+- **Complexity in Orchestration:** managing a large number of containers can introduce complexity, especially without proper orchestration tools.
+
+
+- **Security Considerations:** Containers share the same OS kernel, which can pose security risks if not properly managed (e.g., vulnerability exposure).
+
+
+### Risks
+
+
+- **Vendor Lock-In:** Relying on specific Docker features or services might lead to challenges in migrating to other containerization solutions in the future.
+
+
+- **Configuration Drift:** As applications evolve, keeping container configurations consistent across different environments can be challenging, potentially leading to discrepancies.
+
+
+- **Data Persistence:** Managing data persistence for stateful applications can be complicated with Docker containers, requiring additional solutions like volumes or external databases.
+
 
 ### Related Issues
 

adr/010-iac-terraform.md

@@ -1,4 +1,4 @@
-# 10. Terraform IaC for Deploys
+# 10. Terraform IaC (Infrastructure as Code) for Deploys
 
 Date: 2023-01-04
 
@@ -12,8 +12,7 @@ Accepted.
 
 ## Context
 
-Infrastructure as Code (IaC) is a industry best practice to get repeatable and resilient deployments of applications and
-associated infrastructure into the cloud.
+Infrastructure as Code (IaC) is an industry best practice to get repeatable and resilient deployments of applications and associated infrastructure into the cloud.
 
 There are many IaC options to deploy to Azure.
 
@@ -30,6 +29,46 @@ There are probably even more.
 Terraform is multi-cloud and multi-tool, has a full-featured DSL, tracks state and dependencies, and is agentless.
 Terraform is also used by ReportStream.
 
+## Impact
+
+### Positive
+
+- **Multi-Cloud Support:** Terraform allows deployment across multiple cloud providers (e.g., AWS, Azure, GCP), providing flexibility and avoiding vendor lock-in. 
+
+
+- **State Management:** Terraform tracks the state of your infrastructure, which helps prevent configuration drift and makes it easier to manage changes over time.
+
+
+- **Declarative Language:** The HashiCorp Configuration Language (HCL) is easy to read and write, making it accessible for both developers and operations teams.
+
+
+- **Community, Ecosystem and Version Control:** Terraform has a large community, a wealth of modules, and an extensive ecosystem of plugins and integrations, making it easier to find solutions and share best practices. Storing Terraform configurations in Git allow teams to track changes and roll them back if needed.
+
+
+- **Automation and Integration:** Terraform can be integrated into CI/CD pipelines, allowing for automated infrastructure deployments alongside application code.
+
+
+### Negative
+
+
+- **State File Management:** Managing the state file can introduce complexities, especially in teams where multiple people may modify infrastructure, leading to potential conflicts or errors.
+
+
+- **Dependency Management:** Although Terraform manages dependencies between resources, complex infrastructures may require careful planning and a deep understanding of how dependencies interact, which can complicate deployment processes.
+
+
+### Risks
+
+- **State File Security:** The state file can contain sensitive information, so it's critical to implement proper security measures to protect it (e.g., using remote state storage with access controls).
+
+
+- **Inconsistencies Across Environments:** Without strict version control and practices in place, discrepancies can arise between different environments (development, staging, production).
+
+
+- **Vendor Lock-In:** While Terraform itself is multi-cloud, reliance on specific providers' features or modules can lead to some level of vendor lock-in over time.
+
+- **Tool Updates:** Regular updates to Terraform or its providers could introduce breaking changes or require modifications to existing infrastructure code, which might affect ongoing deployments.
+
 
 ### Related Issues
 

adr/011-dast.md

@@ -1,9 +1,12 @@
-# 11. OWASP ZAP Dynamic Application Security Testing
+# 11. OWASP ZAP Dynamic Application Security Testing (DAST)
 
 Date: 2023-02-06
 
 ## Decision
 
+- **OWASP** - [Open Web Application Security Project](https://owasp.org/about)
+- **ZAP** - Zed Attack Proxy 
+
 We will use [OWASP ZAP](https://www.zaproxy.org/) for DAST scanning of our application.
 
 ## Status
@@ -12,15 +15,48 @@ Accepted.
 
 ## Context
 
-Zed Attack Proxy (ZAP) is a free, open-source penetration testing tool being maintained under the umbrella of the Open Web Application Security Project (OWASP). ZAP is designed specifically for testing web applications and is both flexible and extensible.
-- Has Docker image which allows for an isolated testing environment.
-- It is open source and widely used.
-- Provides crossed-platform.
-- Has extensive community support.
-- Can generate reports.
+ZAP is a free, open-source penetration testing tool maintained under the umbrella of the Open Web Application Security Project (OWASP). ZAP is designed specifically for testing web applications and is both flexible and extensible.
 
 [Reference](https://www.zaproxy.org/getting-started/)
 
+## Impact
+
+### Positive
+
+- **Integration Capabilities:** ZAP can be integrated into CI/CD pipelines, enabling automated security testing as part of the software development lifecycle.
+
+
+- **User-Friendly Interface:** ZAP has an easy-to-use interface that simplifies the process of running scans and analyzing results, making it accessible for teams with varying levels of expertise.
+
+
+- **Comprehensive Reporting:** ZAP can generate detailed reports that help identify vulnerabilities and guide remediation efforts, useful for compliance and audits.
+
+
+- **Community Support:** The active community surrounding ZAP provides a wealth of plugins, resources, and support, facilitating easier troubleshooting and best practices sharing.
+
+### Negative
+
+- **Learning Curve:** Teams new to penetration testing tools may face a learning curve to fully leverage ZAP's capabilities.
+
+
+- **Resource Intensive:** Running ZAP scans, especially on larger applications, can consume significant system resources and impact performance during testing.
+
+
+- **False Positives:** Like many DAST tools, ZAP may produce false positives, requiring additional time for manual verification of identified vulnerabilities.
+
+
+- **Limited Advanced Features:** While ZAP is powerful, it may lack some advanced features found in commercial DAST tools, such as specialized vulnerability assessments.
+
+
+### Risks
+
+- **Configuration Errors:** Incorrect configuration of ZAP may lead to incomplete scans or misinterpretation of results, potentially leaving vulnerabilities undetected.
+
+- **Production Systems Impact:** Running DAST scans on production environments can introduce performance issues or impact user experience if not managed carefully.
+
+- **Reliance on Community Support:** Relying on community resources for troubleshooting can lead to slower issue resolution compared to commercial tools with dedicated support.
+
+
 ### Related Issues
 
 - #77