• Business Requirement Definition: New product needs are identified based on customer feedback, internal team requirements, suggestions from the business development team, and market surveys. At this stage, we articulate the problem statement and the expected outcome.

• Technical Feasibility Study: Based on the requirements, a feasibility study is conducted to assess the operational, technological, and human resource requirements for the product. The viability of the product development request in relation to the existing product pipeline is determined.

• Partner Impact Assessment and Communication: Every new development request is further reviewed to identify the impact on existing Partners. All relevant information is shared with the impacted Partners, and discussed and explicit sign-off is taken. If a new partner is being onboarded, a review of the proposed product is conducted, and it is signed off by the partner.

• Software Design Requirements (SDR): The product development team works on building a product workflow that would divide the requirement into different modules and lay out the required functionalities to achieve the desired outcome.

• Baseline Security Requirement Definition: The security team internally analyses the software design requirements specifically in the context of security vulnerabilities and identifies the key protocols that the team will need to follow throughout the development process.

• RACI Creation: To ensure clear accountabilities, the scope is divided into different workstreams that work on the development of the SDR with an additional workstream focused on security exclusively. Our security team evaluates and tests all development at the time of completion of each milestone purely through a security lens. They establish the essential security measures that must be adhered to during the development of each module, based on the finalized Design Approach.

• Detailed Design Requirements (DDR): Based on the SDR, the product architects create three different approaches to meet the requirements through backend development keeping in mind the predefined baseline security requirements.

• DDR Finalisation: The Product Leads evaluate the proposed DDRs based on project feasibility, development timeline, costs, and a variety of security-related measures such as development risk, 3rd party exposure, etc.

• Project Plan and DevOps Setup: Once the final DDR is chosen, the Project team works with the Product team to create a comprehensive project plan which is divided into sprints. At each milestone, security testing, functional testing, and source code review are mandated before sign-off. Furthermore, each outcome and review is mapped on DevOps with specific owners to ensure complete accountability.

• Test Case: The Development and Product teams collaborate to create a comprehensive list of test cases with expected outcomes for each milestone and the entire scope of development.

• Misuse and Abuse Case: All vulnerable points where the user or an external malicious party could potentially misuse the provided functionality are determined and checks are put into place.

• Threat Modelling: The DDR is scrutinized to identify potential vulnerabilities and risks at each stage of the product and mitigation plans are put in place by the Development and Security Team.

• Partner Branding and Operational Risk Sign-Off: On completion of application design, the relevant wireframes are shared with Partner Marketing Teams for sign-off on their branding. Additionally, all operational risk-related details such as fields stored, consents taken, stages of data collection and storage are shared with Partners for review and sign-off.

• Partner Content Sign-Off: Any updates to key content in the new application such as terms and conditions etc. are notified to the partner and sign-off is taken.

• Unit Testing: The Product team conducts complete product functional testing after every milestone against the expected outcomes defined in the test cases and identifies any vulnerabilities. In addition, the Security team reviews the error logs and runs independent stress tests to identify vulnerabilities. Only on closure and sign-off from both teams is the milestone deemed closed.

• Secure Code Review by Cert-In Empanelled Auditor: Security experts including third-party audit firms perform in-depth manual code reviews, identifying subtle security vulnerabilities that automated tools might miss. Manual reviews assess the logic and architecture of the application to uncover issues that could lead to data breaches or unauthorized access.

• Input Validation Testing: It involves sending random and unexpected inputs to the application to identify if the application can handle such inputs and if not, how it reacts. Fuzzing can be used to identify security vulnerabilities such as buffer overflows, cross-site scripting, etc.

• Penetration Testing (Pen Testing): Penetration testers simulate sophisticated attacks to uncover vulnerabilities and security gaps. By exploiting weaknesses, pen testers evaluate the application's resilience against real threats and provide valuable insights into its security posture.

• Accessibility and Localization Testing: To cater to the complete target market focused testing for disability-based usage and language-based localization is undertaken for the complete development.

• SQL Injection Testing: Application databases are tested to ensure that they are resistant to SQL injection attacks, which attempt to manipulate or gain unauthorized access to the database.

• Dynamic Analysis Security Testing (DAST): DAST tools are used to simulate real-world attacks on the running application. They identify vulnerabilities that might only manifest during runtime and interactions with external components.

• Container and Image Scan: The infrastructure used to deploy the software developed such as servers, containers, and network are analysed for vulnerabilities and mitigation steps are undertaken. Further, all images and artifacts used are analysed separately as well.

• Session Management Testing: This testing verifies that session tokens are correctly managed, preventing issues like session fixation and session hijacking.

• Performance and Load Testing: These tests help ensure that the application can withstand heavy loads and unexpected spikes in traffic, which can sometimes lead to security vulnerabilities.

• Continuous Integration/Continuous Deployment (CI/CD): We leverage CI/CD pipelines on DevOps to automate the deployment process, enabling consistent and repeatable deployments.

• Legal and Compliance Sign-Off: Prior to any release, the complete product is shared with the Legal and Compliance team for sign-off. The same is done with Partner teams. Any inputs or changes are incorporated.

• IDR Setup: IDR stands for Intrusion Detection and Response. This activity involves monitoring the software and network for signs of intrusion and responding to incidents by taking appropriate actions to contain and remediate the intrusion. This helps to prevent or minimize the impact of security incidents.

• Incident Response Matrix: In case of any security incidents detected or reported a clear plan is put in place for the response with tagging to identified resources.

• Security Verification: A final security assessment is performed before the application goes live. This includes penetration testing, vulnerability scanning, and security reviews to ensure that the deployment doesn't introduce vulnerabilities.

• Monitoring and Logging Setup: Monitoring and logging tools are configured to track the application's behaviour in the production environment. It ensures that logs capture relevant information for troubleshooting and security analysis.

• Staging and Production Code Cleanup: A complete check of existing code takes place to remove development-level data and security rules and enable dynamic secure input of passwords, an encryption protocol, partner-based identification, etc.

• Release Coordination: We coordinate the release activities with development, testing, and operations teams. Ensure that all team members are aligned with the release plan and that any potential conflicts or dependencies are addressed.

• Deployment Plan Execution: We execute the deployment plan that was prepared during the earlier planning stages. Follow a controlled and well-documented process to ensure that the application is rolled out without disrupting existing systems.

• Version Control and Tagging: Version control systems are used to manage the application's codebase. Appropriate version tags are applied to ensure that the deployed version is accurately identified and can be traced back to the source code.

• Configuration Management: Consistent configurations are applied to all components of the application, including servers, databases, networking, and third-party integrations. It helps maintain security and stability.

• Access Level Protection: On completion of development all code is moved to a protected file with limited access to Product Owners for Development, Staging, and Production. Access from all Developers and Reviewers is removed in the development space and data deletion is conducted on individual machines.

• Partner Testing Setup: On completion of development and sign-off at testing stage of Partner's APIs / SDKs on Testverse, their actual APIs or SDK are tested at this stage at the Staging stage and integrated into the development. Further, before the release of APK/IPA is shared with all Partners for sign-off. To enable this each Partner's devices and IP are whitelisted and role-based access control is configured to ensure limited exposure and seamless testing.

• APK/IPA Package: We do share APK/IPA package with partners that includes:
  • Application Code, Resources, and Assets
  • Installation & Usage Instructions
  • Digital Signature Information
  • Secure Code Audit Report
  • Release Notes (Change Logs, Enhancements, Bug Fixes, Device Compatibility)

• Sign-Off from Partners: Impacted partners needs to provide sign-off on the release within defined timelines.

Major Release 7 Days	It is a significant version of a software application or product. It indicates a substantial update, typically characterized by significant new features, enhancements, improvements, and sometimes changes to the overall architecture. Major releases often come after a period of development and may involve changes that impact the user experience, functionality, and even the underlying codebase.
Minor Release 3 Days	It is a type of software release that includes incremental changes to an application or product. Unlike major releases that introduce significant new features and changes, minor releases focus on smaller enhancements, bug fixes, and improvements without radically altering the application's functionality or architecture.
Hotfix 1 Day	It is a type of software update that is deployed to address critical issues or vulnerabilities in an application or system. Hotfixes are released outside of the regular update cycle to quickly resolve urgent problems that could impact the functionality, security, or stability of the software. These fixes are often deployed as soon as they are available to minimize the impact of the issue on users or the organization.

• Testing in Beta Environment: Additional testing is conducted in a beta environment to verify that the application performs as expected and interfaces seamlessly with other systems and services.

• Testing in Staging: Final testing before deploying changes for public. Any reported issues are addressed before moving forward with the deployment.

• Performance Monitoring: We do monitor the application's performance in the production environment. We also track key metrics such as response times, resource utilization, and user satisfaction to identify any performance bottlenecks.

• Rollback Plan: We have a well-defined rollback plan in case deployment issues arise. This plan outlines the steps to revert to the previous version quickly and effectively while minimizing downtime.

• Post-Deployment Review: We do conduct a post-deployment review to evaluate the success of the deployment process. Strengths, weaknesses, and areas for improvement are identified to enhance future deployment efforts.

• Prepare User Documentation: At the end of every development user documentation is prepared on how to use the application, and common FAQs are listed and pre-emptively addressed. The same is circulated with the internal Experience team.

• Prepare System Documentation: The complete development lifecycle is documented at a module level with a functionality-wise breakdown for reference to all developers. Development owners for enhancements and bugs are identified and marked to the product.

• Handover to the Operation and Support Team: Finally, the Experience and Business Development teams are handed over the product with the standard reporting process for issues and incidents. Thresholds for issue types are set and an escalation matrix is put in place to ensure immediate and effective resolution.

Code exposure is the risk of coding getting leaked or shared with unauthorised parties. Through the development and deployment cycle, there is a constant risk of code exposure. We take multiple steps to prevent the same. By limiting testing to a certain set of IPs and devices the complete product can't be implemented and viewed on any device even with access to the code. Further, all code is obfuscated on sharing. While development takes place on different branches only tenured senior resources conduct merge activities and on completion of the development of a module code access is taken away and only granted after a chain of approvals. While this allows us to maintain confidentiality and protection of the code through the development lifecycle it hampers sharing of the application with external parties till the deployment stage as the application isn't compiled till the last stage.

The chances of human error exist in every process. During the development process, the risk of people leaving their laptops unattended, code getting stolen on public networks, etc. always exists. This risk continues to exist throughout the SSDLC lifecycle. We implement strong MFA password protection for authentication on all devices, including testing devices. Further, work can only be committed, released, and accessed from our whitelisted IPs. To mitigate for the risk, post-deployment as well we have limited access protocol where the source code access is restricted, and any changes are assigned in smaller feature developments as well. Our existing protocols on device and password protection lead to a lengthier process of testing and development build release due to several physical restrictions imposed. Only at the deployment stage, post-Auditor and Security team sign-off does the scope for remote testing open up.

Whilst we protect using best-in-class software and coding guidelines for external threats one must account for internal threats as well. Employees stealing code, and product ideas are a real risk every organization faces. To minimise the potential impact of this we ensure that our development is broken into small pieces of work and no coder has access to the larger project. Further, the final production code has limited access. In addition, a weekly security check of all devices is done. We also use private and protected versions of external tools which prevents the sharing of code outside of the company domain. Our protections against malicious intent get significantly reduced post the deployment stage as the complete product access lies with a limited set of people. This, however, makes sharing with external domains for reviews a complicated process. As policy, we share only completely signed off product for testing to protect against malicious intent or security lapses on Partner or 3rd party side.

Loss of key personnel risk exists in every organization. In a product setup, the chance of this loss is to competition with key coding and product knowledge. This risk largely exists during the product planning and development phase. Apart from standard legal protocols, we protect against this by having a maker-checker policy at every stage which ensures more than one person has end-to-end knowledge of all facets of a particular feature or module. In addition, the distribution of work into siloed parts allows the loss to be minimal. Also, in the event of an employee parting ways with the organization, immediate data handover and restricted access protocol are put into place.

The chance of loss of laptops, and testing devices through theft or misplacement exists. All our devices have MFA authentication functionality built-in with a centralized manifest of authorization per device. This allows a complete check to be implemented as soon as such an event is reported. Further, all devices are enabled with a remote memory wipeout facility that allows us to delete all sensitive material as needed.

Working with multiple partners is core to OneBanc's business model. We are constantly onboarding new banking, merchant, and payroll partners the vulnerability of exposure is heightened. This risk is particularly heightened during the development and integration phase due to new developments causing vulnerabilities and complete testing of Partner provided resources not being complete. To counterbalance this, all new developments from Partners are first tested through our independent testing platform, TestVerse, and replicated on Emulator for functional testing. They are exposed to the main product only after completing all security checks and development requirements from the Partner. This leads to an additional sprint of testing with Partner APIs and SDKs at the time of final compilation and APK/IPA creation as the services aren't ever exposed to the application before that.