Software Development Life Cycle (SDLC) Policy

Helpjuice

____________________________________________________________________________

Purpose
This policy defines the high-level requirements for providing business program managers, business project managers,
technical project managers, and other program and project stakeholders guidance to support the approval, planning, and
life-cycle development of Helpjuice software systems, aligned with the Information Security Program.

Roles and Responsibilities

• Policy Owner: Updates, reviews, and maintains this policy annually or as needed.
• IT/Security Teams: Enforce technical safeguards and monitor compliance.
• Employees/Contractors: Adhere to data classification guidelines and report incidents.

Policy
Helpjuice must establish and maintain processes for ensuring that its computer applications or systems follow an SDLC
process which is consistent and repeatable, and maintains information security at every stage.

Software Development Phases and Approach Standard

A Software Development Project consists of a defined set of phases:

Determine System Need Phase

The Determine System Need phase is the period of time in which an information system need is identified and the
decision is made whether to commit the necessary resources to address the need.

Define System Requirements Phase

The Define System Requirements phase is the period in which the User Requirements are broken down into more
detailed requirements which can be used during designing and coding. Applicable security requirements and controls
will be identified through an information security risk assessment.

Design System Component Phase

The Design System Components phase transforms requirements into specifications to guide the work of the
Development phase. The decisions made in this phase address how the system will meet the functional, physical,
interface, data, and security requirements. Design phase activities may be conducted in an iterative fashion, producing a
system design that emphasizes the functional features of the system and technical detail.

Build System Component Phase

The Build phase transforms the detailed system design into complete coded software units and eventually, into an
integrated product for release. Each software unit and subsequent integrated units are tested thoroughly, to include tests
for security vulnerabilities. System documents that support installation and operations are also developed in this phase.

Evaluate System Readiness Phase

The evaluation phase ensures that the system, as designed and built, satisfies the requirements of the user, as well as
applicable security requirements. Whenever possible, independent testers measure the system's ability to perform the
functions that are required by the customer and ensure an acceptable level of quality, performance, and security. Once
the phase is complete, it will be evident whether or not the system is ready for operation or redevelopment.

System Deployment Phase

System Deployment phase is the final phase of the development life cycle, when the system is released initially to a
pilot site, where any further security vulnerabilities can be identified, and then into the production environment. All
necessary training for using the system is accomplished.

Project Management

The sequence of the development phases depends on the software development approach taken. The project
management approaches include but are not limited to:

• Waterfall Development
• Agile Development
• Iterative Development
• Staged Delivery Development

Based on the approach for and the size of the software development, some of the phases can be combined. In Iterative
Development there may be multiple Cycles (iterations) of the above phases before the final software is released.

SDLC Security Control Guidelines

The SDLC process will adhere to the following information security controls:

• Adequate procedures should be established to provide separation of duties in the origination and
approval of source documents. This shall include but not be limited to separation of duties between
Personnel assigned to the development/test environment and those assigned to the production
environment.
• Modification of code or an emergency release will follow the change control standard.
• Secure programming standards should be followed.
• Secure development environment will be created, based on:
◦ sensitivity of data to be processed, stored and transmitted by the system;
◦ applicable external and internal requirements, e.g. from regulations or policies;
◦ security controls already implemented by the organization that support system development;
◦ trustworthiness of personnel working in the environment;
◦ the degree of outsourcing associated with system development;
◦ the need for segregation between different development environments;
◦ control of access to the development environment;
◦ monitoring of change to the environment and code stored therein;
◦ backups are stored at secure offsite locations; and,
◦ control over movement of data from and to the environment.

• Threat modeling, incident reviews, use of vulnerability thresholds or contingency planning will be
conducted to ensure the architecture and design of information systems are protected against known
threats based on the operational environment.
• All software deployed on Corporate or Hosted infrastructure must prevent security issues including but
not limited to those covered by SANS and OWASP.
• Static application security testing (SAST) tools or equivalent tools should be used as part of the CI/CD
pipeline to detect vulnerabilities in the code base. When vulnerabilities are identified, corrections
should be implemented prior to release as appropriate based on the nature of the vulnerability.
• Code changes are reviewed by individuals other than the originating code author and by individuals
 who are knowledgeable in code review techniques and secure coding practices.
• Overrides of edit checks, approvals, and changes to confirmed transactions should be appropriately
authorized, documented, and reviewed.
• Application development activity should be separated from the production and test environments and
the separation should be enforced with access controls. The extent of separation, logical or physical, is
recommended to be appropriate to the risk of the business application or be in line with customer
contractual requirements. The level of separation that is necessary between production, development,
and test environments should be evaluated and controls established to secure that separation.
• Test environments are designed to match production environments as closely as possible.
• All changes to production environments should strictly follow change control procedures, including
human approval of all changes, granted by an authorized owner of that environment. Automated
updates should be disallowed without such approval. Approval requirements will be enforced through
automated mechanisms where possible (e.g., branch protection settings on production code
repositories).

Individuals who are responsible for supporting or writing bespoke or custom software, will be required to complete
annual security training specific to secure coding practices. For individuals supporting or writing code for an internet-
facing application, training should also include topics specific to internet threats. The individual should complete the
training prior to writing or supporting the code. The training must include OWASP secure development principles as
well as OWASP top 10 vulnerability awareness for the most recent year available.

• Custom accounts and user IDs and/or passwords should be removed from applications before
applications become active or are released to customers.
• Production data should not be used in testing or development environments.
• Security controls that are in place for the production copy in the test system should be production
quality (e.g. mirroring the production controls over the data).
• When conducting quality assurance (QA) testing prior to the release of a new feature requiring user
input where constraints on user input may be reasonably understood, feature acceptance tests must
include testing of edge and boundary cases.

For situations demonstrating that testing needs to use production data, the requirements are the following:

• The Information Resource Owner will provide approval before production data can be used for testing
purposes.
• Wherever possible, the production data should be tokenized, anonymized, removed, or de-identified instead of
using production data.
• Testing and parallel runs should use a separate copy of production data and the test location or destination
should be acceptable (e.g. loading confidential production data to a laptop for testing is not acceptable).
• The data should not be extracted, handled, or used by the test process in a manner that subjects the data to
unauthorized disclosure.
• The data should be accessed on a need-to-know basis with the same access control procedures as operational
environments.
• The data should have a separate authorization each time operational information is copied to a test
environment.
• Copying data into the test environment should be logged for an audit trail.
• Normal test activities should not use production data. In cases where test activity requires access to
production data, access to production data should be restricted to only those individuals who have a
documented business need. Only the information with the documented business need should be accessible by
those users.
• Production data used for testing should be securely erased upon completion of testing.
• Test data and accounts will be removed before placing new and updated systems into production.
• Restricted/Protected Information will be encrypted according to the Encryption Standard while at rest or in
transit.
• Error messages must be handled securely and they must not leak sensitive information.
 Application Programming Interface (API) Availability
Helpjuice will provide the following application interface(s) to customers, enabling them to programmatically retrieve
their data for improved interoperability and portability.

Helpjuice offers a comprehensive API for our services, specifically the Helpjuice API V3, which is structured around
REST, HTTP, and JSON. Here are some key features and functionalities of our API:

Base URL
The API is accessed using a base URL specific to your account. The general format for the API endpoint is:

[Link]

Authentication
All requests to the API require authentication through your API key. This key can be provided as an HTTP header
named Authorization or as a api_key query parameter. You can find your API key in your account under the Settings/
API Credentials page. For more details on obtaining your API key, please refer to this article.

HTTP Methods
The API uses standard HTTP methods to indicate actions on resources:

GET: Retrieve a resource

POST: Create a new resource
PUT: Update a resource
DELETE: Remove a resource

Available Endpoints
Retrieve Answers: Use the following URL to retrieve answers:
[Link]
Retrieve Searches: Use this URL to retrieve searches:
[Link]
Retrieve Questions: To get questions, use:
[Link]
Retrieve Categories: Access categories with:
[Link]

Available APIs:

• [Link]
• [Link]
readings?from_search=170511820&swifty_search_highlight=API

These APIs are designed to support interoperability between components and facilitate the secure
migration of applications and data between environments. Helpjuice maintains thorough
documentation for API functionality, which is regularly updated and provided to customers
alongside new API versions. Additionally, security considerations are addressed during both the
development and update processes to ensure the highest level of protection for customer data.
Revision History

Version Date Editor Approver Description of Changes Format