Secure Software Development Lifecycle

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

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

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 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

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.

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

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/3^rd 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.

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 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

@Dominik Meyer