Secure Software Development Lifecycle (Secure SDLC) — Unique AI Documentation
Secure Software Development Lifecycle (Secure SDLC)
For software development projects, Unique has implemented a secure software development lifecycle (SSDLC), providing a framework for training, tools, and processes. As security is in the vital interest of anyone who is using Unique products and services to run critical business processes and to store and process sensitive data, secure developed software is a prerequisite for secure operations.
Uniques process bases on and integrates https://www.microsoft.com/en-us/securityengineering/sdl/ in every development stage, ensuring top-notch security from design to deployment.
Phases in Unique Secure Software Development Lifecycle v2.0
Unique is proudly committed to robust cybersecurity and therefore regularly trains employees on secure design essentials: Threat Modeling, Secure Coding, Security Testing, and Privacy. Through creative ideation, Unique tailors its customer-centric solutions to meet and exceed customer needs, ensuring a top-notch experience with every change. Once agreed, Unique blends customer insights, market analysis, and team brainstorming to gather requirements for selected ideas and turns feedback into action. Unique crafts their products with user-friendly UX and cutting-edge software design.With robust security measures, Unique implements the change securely whereafter it undergoes rigorous validation. Uniques process includes extensive tests and detailed code analysis, guaranteeing reliability and excellence. Using continuous integration, deployment and release, the change is then progressively rolled out to Uniques customers. Not being done and continuously monitoring the changes and system, Unique's incident response swiftly tackles software hiccups to minimise downtime.
Turning the idea of a lifecycle into action, the Unique SDL processes below implement these phases…
Process
With the philosophy and phases in mind, Unique has designed and implemented the Secure Software Development Lifecycle in its process(es).
Changes to the process
The processes are governed and can't be changed at will. While some of them are part of legally binding contracts changes to the process must always undergo intense review. Therefore the following rules apply to all changes of Uniques SDL processes.
- All processes are visibly versioned
- We constantly evolve our process implementation internally but if changes or a collection of them affects customers, a new version of the Unique Secure Software Development Lifecycle gets published
- Changes must be reviewed and agreed by all stakeholders
- Changes must be communicated to affected customers with a considerable notice period, whereafter amendments can be made before the new, changed version gets published
RACI / Stakeholders RACI
Unique SSDL process involves all relevant teams and thus they all become stakeholders. Namely:
| Team | RACI |
| Development | Accountable and responsible for process and its implementation |
| Operations
Customer Success
UI/UX Design
Security | Consulted when implementing and changing the process |
| Company | Informed upon changes |
Process Definition
TRAINING
Uniques training activities are documented and outlined in internal resources:
- Security Manual for Development and Operations
- Awareness Campaigns
- Threat Modelling Resources
IDEATION
| Activity | Role: Tasks | Outcome | Security Controls |
|---|---|---|---|
| v2.0 | |||
| Collect ideas | Any source: Submit and vote on ideas Product: Triage ideas incl. security impact |
List of ideas, some over threshold | Ideas get triaged with a clear security focus in mind |
| Prepare selected ideas | Product: Prioritise ideas above threshold and inform Customers | Prioritised selection of ideas that should go into requirements specification | Selected ideas undergo a first risk assessment, probably insecure changes are rejected |
REQUIREMENTS
| Activity | Role: Tasks | Outcome | Security Controls |
|---|---|---|---|
| v2.0 | |||
| Appoint project lead and team | Product: Select responsible team for the feature | Implementing team and responsible PL selected | Subject matters experts are preferred leads or at least consulted |
| Gather requirements | PL: Convert idea from sketch to change with concrete requirements and a specification | Product specifications as specs, story or tickets as well as KPIs to measure value | Acceptance criteria incl. security criteria |
| Explore product fit | PL: Consult UI/UX and Customer Success to determine whether the drafted change matches the overall product | Specifications on how the change is to fit E2E into the product | |
| Determine feasibility | PL: Consult subject matter experts and architects to determine feasibility of change and get first effort estimations | First estimations for the roadmap | Reliability of the system is vital, thus changes absorbing too many resources for a longer period must be revisited or broken down |
| Perform risk assessment | PL: Consult security and perform risk assessment | Accepted change, Accepted change with mitigation or logged risk or Rejected change | Risks get assessed as defined in ISMS Risk Management |
| Document AI System Rationale | Product: Document the business case, customer request, or policy driving the AI system. | Clear understanding of the purpose and goals of the AI system including business case. | Documentation of purpose and goals of the AI system was created. |
DESIGN
| Activity | Role: Tasks | Outcome | Security Controls |
|---|---|---|---|
| v2.0 | |||
| Design UX/UI | UX/UI: Design visual parts and E2E experience/flow of the change | Design specifications, linked to the tickets | |
| Design technical implementation | Architecture/Dev: Define implementation, investigate need for threat modelling (security, privacy or cryptography) Security: Consulted for need of threat modelling |
Software design specifications, scheduled threat modelling workshop | Workshops scheduled if needed for security, privacy and/or cryptography |
| Select AI Model | Data Science: Choose the appropriate model type. | Defined model. | Model fulfills compliance requirements and contracts. |
| Threat modelling workshop for changes that affect security posture (confidentiality, integrity and/or availability) including AI usage | Product, Architecture: Provide architecture diagram of design Dev: Provide input during workshop Security: Moderate workshop |
Threat modelling workshop report Tasks to reduce identified threats or logged risks |
Change has a threat modelling workshop report and tasks to reduce threats defined which was moderated by security |
| AI Impact Assessment | Data Science: Provide input during workshop Compliance: Moderate workshop |
Comprehensive impact assessment report, including mitigation strategies for identified risks | AI Impact Assessment report including mitigation measures was created |
| Define necessary documentation | PL: Specify with Customer Success which documentation is expected | Defined formats of documentation, e.g. how-to articles, tutorials, descriptions etc. | |
| Draft rollout plan | PL: Decide, how this change will later be rolled out | Rollout plan as in: immediately GA, with preview testers, just for certain companies first, no one at first etc. | Unique does progressively rollout/release changes to customers, this reduces the overall risk as a change reaches a smaller audience first so the impact is smaller |
| Assess tenant scalability | Operations: Determine if current change is applicable to all tenant models | List of required design changes to accomodate all tenant models | The change must fit the security-wise tightest tenant model so that it can later rollout to all models equally |
| Define resilience and monitoring criteria | Operations: Specify, which requirements have to be met so that the change can resiliently run and be monitored later on | Specifications on how the change must be made resilient and gets monitored | As Availability and Integrity are security goals, designing changes resiliently is a must - ISMS Master Security Policy |
| Plan for Poor AI Performance | Data Science: Develop mechanisms to handle poor AI performance | Contingency plan for poor performance |
IMPLEMENTATION
The word pull request for a change is avoided on purpose. The process shall not state a tool and while a change at GitLab is a merge request at GitHub it is a pull request. Thus Uniques changes are simply change requests but they clearly talk about source code.
| Activity | Role: Tasks | Outcome | Security Controls |
|---|---|---|---|
| v2.0 | |||
| Provide documentation | Dev: Write documentation on the newly provided change Dev: Write concise change request body |
Documentation, Release notes content | |
| Implement AI System Rationale | Data Science: Continuously verify and improve the implementation based on the purpose and goals defined for the AI system | Refined and optimized implementation | |
| Implement AI Impact Assessment mitigation measures | Data Science: Implement mitigation measures | Secured AI system | |
| Write automated tests | Tester: Write relevant tests to cover the new functionality especially edge cases Data Science: Provide representative test data for AI model tests |
New test cases added to the automated test suite | Test are reviewed to not only test the new changes happy flow but also insecure or privacy-violating cases |
| Static Code Analysis | Security/Automation: Perform code scan | Code scan results | Changes with failed code scans are not allowed to proceed, exceptions are possible if risks get logged in ISMS Risk Management |
| Dynamic Code Analysis | Security/Automation: Perform security test | Security test results | Unique does not perform DAST scans per change or quarterly but continuously via a Bug Bounty program |
| Validate changes locally | Dev: Testing their changes locally to ensure all requirements are met Reviewer: Equally validates and tests the code locally trying to break it or even out of it |
Functional change request | Local testing provides a first set of barriers to not ship completely untested code |
| Implement change from Design phase | Dev: Repeatedly iterate the change. Where possible code is written with pair-programming Reviewer: (Repeatedly) review (functional and non-functional) the change until all gates are passed |
Change Request including tests, documentation, monitoring and alerting, release notes and referenced ticket | Change Requests without 4-eye approval are rejected and the change cannot proceed, see Pull Request Guideline. Break-glass exceptions are possible but the incident gets logged and we notify necessary parties, see SOC2 Overview. |
| These steps get repeated so often, until all requirements pass! Changes can be broken down into smaller changes (shift-left and change small, change often paradigms of Secure DevOps) - the process then applies to each child-change itself. |
VALIDATION
| Activity | Role: Tasks | Outcome | Security Controls |
|---|---|---|---|
| v2.0 | |||
| Run all test suites | Automation: Verify change once more to ensure that no breaking code has made it through | Green pipeline and product that passes all unit, request, e2e and regression tests | If any suite fails, the change is not progressing and the team must with urgency find the culprit as the continuous delivery is blocked |
| 📦 Deploy change to quality assurance environment(s) | Automation: Deploy change | Product with latest change is deployed to QA environment(s) | No manual deployments are performed at Unique, all deployments are done via automations, infrastructure or configuration as code |
| Smoke test the environment | Automation: A small smoke test fleet is ran against the environment to ensure it is still running | Upon failure, the change gets reverted and the pipeline blocked | If they fail, the change is not progressing and the team must with urgency find the culprit as the continuous delivery is blocked |
| Perform User Acceptance Tests | PL: Validate the product change Customer Success: If desired, test the product changes as well |
Change validated against all specifications and requirements | |
| Perform penetration tests | Tester: Penetration test | Test results and action items to fix eventually found issues | Unique does not perform penetration tests per change or quarterly but continuously via a Bug Bounty program |
| Validate implementation of threat mitigation measures | PL, Security: Check if mitigation tasks are done within defined due dates | Reprioritisation in case of deviations | Report that threats were mitigated as planned |
| Validate implementation of AI Impact Assessment mitigation measures | Security: Validate that mitigation measures defined in AI impact assessment were implemented | AI Impact Assessment mitigation report | Report that AI risks were mitigated as planned |
| Validate AI System Rationale | Data Science: Validate the AI system's purpose and goals fulfillment | AI system that implements its purpose and goals |
ROLLOUT
Uniques different tenant models allow for more granularly controlled rollout processes in the most secure setups.
Continuous rollout
The continuous rollout applies to all Unique multi-tenant systems, especially unique.app.
| Activity | Role: Tasks | Outcome | Security Controls |
|---|---|---|---|
| v2.0 | |||
| Deploy to production | Dev: Deploy the change to Uniques production system(s) | Change is deployed | |
| Update SBOM | Automation: Update Software Bill Of Materials | SBOM is updated | The SBOM is the base for external/client/3rd party vulnerability scanners. |
| Smoke test the environment | Automation: A small smoke test fleet is ran against the environment to ensure it is still running | Upon failure, the change gets reverted and the pipeline blocked | If they fail, the change is not progressing and the team must with urgency find the culprit as the continuous delivery is blocked |
| Release change to planned audience | PL: Release the deployed change (make it available) for the planned audience | The destined subset of users can see/use the change | Unique does progressively rollout/release changes to customers, this reduces the overall risk as a change reaches a smaller audience first so the impact is smaller |
| Publish documentation | PL: Publish documentation about the new feature, how-to guides, tutorials and similar as they were previously selected | Documentation is publicised | Publishing documentation requires a peer-review as well as once a feature is documented it becomes more visible |
| Validate change or its result against Definition of Done | Dev: Cycle back and validate, that the Definition of Done is met PL: When writing the release notes, iterate the DoD and request changes where needed |
Either follow-up tickets or ticket moves to done. | The Definition of Done fosters and demands that secure coding practises, threat modelings and scans are performed. |
Regular rollout
Regular rollouts are performed towards the tenant models single-tenant, customer-managed tenant and on-premise installations.
| Activity | Role: Tasks | Outcome | Security Controls |
|---|---|---|---|
| v2.0 | |||
| Pin release | Automation upon request: Forge current state of product into a Unique release | A pinned version of the product, melted into one release | Pinning the version ensures that customers only receive a specific version that has been previously tested against Uniques QA and Production environment and not the lastet changes |
| Publish release to delivery repository | Automation upon pinning: Promote pinned Unique release to delivery repository and artifactories | One Upgrade and Release Process | The delivery repository ensures, that only code that passed the complete validation pipeline leaves Unique permises |
| Deploy pinned release to Unique single-tenant quality assurance environment | Automation upon request: Deploy latest Unique release and inform teams | Latest Unique release deployed so it can be validated. | Unique single-tenant quality assurance environment underlies the same PIM permissions as other tenants and thus duties are segregated per role so no developer can deploy without further approval |
| Perform User Acceptance Tests | PL: Validate the product change against single-tenant Customer Success: If desired, test the product changes as well |
Change validated against all specifications and requirements with focus on the regulary-shipped tenant models. | |
| Publish release notes | Automation: Gather changes since the last regular release PL: Compose release notes from automation output Customer Success: Pair-review the notes to ensure target audience understands |
Release notes | |
| Communicate release | PL: Inform Customer Success Customer success: Signal customers if needed, that their requested changes are available in the latest release |
Informed affected or requesting customers |
Single-Tenant model
Single-Tenant model
This partial process gets repeat for each single-tenant once per release!
| Activity | Role: Tasks | Outcome | Security Controls |
|---|---|---|---|
| v1.0 | |||
| Rollout changes to single-tenant deployment | Deploying Dev: Request PIM profile Approver: Approve PIM request Deploying Dev: Upgrade deployment by triggering automation |
Single-tenant deployment is updated to the latest release | Each tenant is isolated via its own PIM-enabled roles and thus duties are further segregated so it needs at least two humans to upgrade a tenant |
| Validate availability of single-tenant deployment | Deploying Dev: Check that at least login page replies, survey logs and alerts to ensure as well as possible without a profile, that the product is still available | Partial test, that the product is still available | Also checking the logs requires PIM-enabled roles (they are combined in the Deploying role for simplicity in that case though) |
| Inform Customer representative | Deploying Dev: Inform responsible Customer representative | Customer (via representative) is informed that their tenant was upgraded |
Customer-Managed tenant model
Customer-Managed tenant model
This partial process gets repeat for each customer-managed tenant once per release!
| Activity | Role: Tasks | Outcome | Security Controls |
|---|---|---|---|
| v1.0 | |||
| Inform Customer representative | Product: Inform responsible Customer representative | Customer (via representative) is informed that a new Unique bundle is available |
On-Premise model
On-Premise model
RESPONSE
Regular
| Activity | Role: Tasks | Outcome | Security Controls |
|---|---|---|---|
| v1.0 |
Resources
Many other processes or (S)SDLCs were used to compose Uniques own lifecycle and process.
- https://www.microsoft.com/en-us/securityengineering/sdl/practices
- https://www.synopsys.com/blogs/software-security/secure-sdlc.html
- https://snyk.io/learn/secure-sdlc/
- https://www.hackerone.com/knowledge-center/what-ssdlc-secure-software-development-life-cycle#:~:text=It%20is%20a%20set%20of,is%20as%20secure%20as%20possible.
- https://www.sap.com/documents/2016/03/.html