Secure Software Development Lifecycle

For software development projects, Unique has implemented a secure software development lifecycle (SSDL), 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 Microsoft Security Development Lifecycle 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…

1 Process
- 1.1 Changes to the process
- 1.2 RACI / Stakeholders RACI
- 1.3 Process Definition
  - 1.3.1 TRAINING
  - 1.3.2 IDEATION
  - 1.3.3 REQUIREMENTS
  - 1.3.4 DESIGN
  - 1.3.5 IMPLEMENTATION
  - 1.3.6 VALIDATION
  - 1.3.7 ROLLOUT
    - 1.3.7.1 Continuous rollout
    - 1.3.7.2 Regular rollout
      - 1.3.7.2.1 Single-Tenant model
      - 1.3.7.2.2 Customer-Managed tenant model
      - 1.3.7.2.3 On-Premise model
  - 1.3.8 RESPONSE
    - 1.3.8.1 Regular
    - 1.3.8.2 Incident
2 Resources

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

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

Security Manual for Development and Operations (internal Reference)
Awareness Campaigns (internal Reference)
Threat Modeling Resources (internal Reference)

IDEATION

Activity	Role: Tasks	Outcome	Security Controls

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

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

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.