Safety first, last, and always: The seven key stages of secure software development

At its core, secure software development can only happen if you have a framework in place that ensures a constant focus on security. The secure SDLC is such a framework. SDLC is organized as a set of individual components that correspond to seven overarching software development stages.

• Training
• Requirements
• Design
• Implementation
• Verification
• Release
• Response

When working in an agile setup where there is a constant flow of new software features, each software development team repeatedly goes through the SDLC framework to ensure a persistent focus on security.

Read on to understand the setup of the SDLC framework and get actionable tips on how to implement it in your company.

Security training in action — your to-do list

Start your security training on day one
From the moment a new employee joins your team — regardless of role or position, you need to have a strong security training program in place to make sure everyone is speaking the same language.

Provide ad-hoc trainings regularly
Additionally, ad-hoc security training should be carried out on a regular basis to make sure the topic stays top-of-mind and people are aware of new threats or best practices.

Base training content on new threats
Topics such as zero trust, the open web application security project top ten (OWASP), or secure design are currently very relevant. However, it is vital that training content is continuously updated and developed to combat against new types of threats. At TeamViewer, we base the development of our security training on needs we identify during regular tests e.g. patterns found in pen test etc.

Create a security knowledge base
Secure coding resources should be easily available so developers can brush up on relevant topics before starting a particular task. Update your knowledge hub regularly as new security or compliance topics arise and make training material centrally available on an on-demand basis.

Appoint dedicated security specialists to each team
Identify individuals in your organization that are interested in security and offer them the chance to become specialists in the area. Provide your specialists with advanced security training and opportunities to get involved in security-related projects and have a strong collaboration with the security team. As they become more knowledgeable on the topic of security, they can champion security training among their team members. To ensure success, it is important to incentivize participation through acts of appreciation and recognition. Gestures such as awarding security-expert certificates and hosting specially addressed summits will help to keep your specialists engaged.

Use external sources to get the full picture of your security posture
Utilize opportunities to get an outside view of your security such as a certified external IT-security consult. With the support of different kinds of pen tests, vulnerabilities can be identified, mitigated or even fixed.

Stage #2 in a nutshell

To ensure project security requirements are met, define and determine your approach. TeamViewer follows a definition of done (DoD) methodology, which we highly recommend implementing. Enhance project security by establishing a clear plan of action.

Stage #2 in detail

We look further into putting DoD into practice and your security-screen requirements to-do list.

Every software development project, large or small, starts with a set of requirements. Bringing security into the software requirement specification is key to ensuring that security is at the heart of the design. For this reason, TeamViewer has anchored its security requirements in a definition of done (DoD). The DoD is used to assess when work is complete, and the software development is ready to be shipped to the product portfolio.

Security-screened requirements in action — your to-do list

Perform security reviews up front
Put together a team of security experts that can review requirements for new features or software amendments and bring up any security concerns that need to be considered before the feature is implemented.

You may also want to define a minimum acceptable level of security quality. For example, by setting a meaningful bug bar, you can clearly define a threshold for the number of vulnerabilities that can be tolerated and lining out how fast severe vulnerabilities must be fixed.

Assess your data processing impact
Consider whether a new or amended feature requires customer data to be collected, processed, stored, or deleted. Although the General Data Privacy Regulation (GDPR) is focused mainly on protecting the individual’s right to their data. Processing data — and especially personal data — is a big part of security. Consequently, this must be reflected in security requirements to ensure security in each area of data processing.

Have a clear definition of done (DoD) to ensure security requirements
Make clear security requirements a part of your definitions of done to make sure development teams cannot finalize a feature, amendment, or tailored implementation without checking the security box(es).

The definition of done (DoD) defines when software is shippable to the market. The DoD provides a common understanding of quality across the organization and transparency about the quality standards to reach a common goal. The DoD could be a simple document which is valid for the entire organization and shows the requirements to reach the status Done for software. This document needs to be reviewed with a focus on potential security hazards.

Stage #3 in a nutshell

The design stage is where many of the technical details of a product are communicated to clients or internal stakeholders. It is crucial to prioritize security awareness in this stage, as decisions made here significantly impact the final product design. At this stage, TeamViewer collaborates closely with security and privacy experts to ensure the development process is driven forward in the most security-aware way.

Stage #3 in detail

Here we demonstrate how we follow security by design and privacy by default approaches as well as providing you with your security-aware design to-do list.

In SDLC, the design phase is a stage where software developers define the technical details of the product. Depending on the project, these details can include screen designs, databases, sketches, system interfaces, and prototypes. Clients or internal stakeholders use these details to make final product design choices. Being security-aware in the design phase helps to identify security concerns early so that they can be avoided all together in the implementation process, which can prevent slowdowns at the end of a project due to unforeseen risks.

TeamViewer follows the security by design and privacy by default approach. In line with this, TeamViewer involves security and privacy experts from the stage of designing the functionalities and requirements. This helps us to identify security concerns early and to prevent slowdowns at the end of a project due to unforeseen risks.

To improve quality and ensure a common understanding of the goal, TeamViewer provides a set of agreements that informs each involved team when requirements are ready to begin — the so-called definition of ready (DoR). It is widely accepted that the quality of requirements has a direct impact on the productivity of development. For this reason, it is important to have security requirements already placed in the DoR.

Security-aware design in action — your to-do list

Perform threat modeling
Provide threat modeling resources for development teams to self-identify security risks as part of the design phase. Threat modeling is a core element of the security development lifecycle (SDLC). It’s an engineering technique used to identify threats, vulnerabilities, and appropriate countermeasures for potential attacks. Based on the information you collect when you do threat modelling, you may change certain aspects of your software design to make it more resistant to attacks. TeamViewer provides threat modeling resources for teams to self-identify security risks as part of the design phase and to know if they are ready to start the design.

Create attack surface mapping
The attack surface of a software solution refers to anywhere where an attacker can try to enter, manipulate, or abstract data from a system. It is a good idea to scan your entire solution with so-called discovery scans that map out every possible attack surface so your team can identify point of entry that may be open even though this was not intended.

Use the security by design approach to reduce impact und effort
Organizations need to consider privacy and security from the first design stages and throughout the complete development process of any new products, processes, or services. Taking this proactive approach is preventive and reduces the effort that needs to be put in for reactive measures and adaptations. Additionally, it contributes massively to end-to-end security. For this reason, it is important to involve security experts in an early stage of the development processes and participation in the design phase to implement the corresponding requirements is current best practice.

Offer security consultations
Your security expert(s) should be available for consultation to review a design as part of a final check prior to a release.

Stage #4 in a nutshell

Based on your security-aware design, your software should be ready to be securely coded and, overall, the implementation should be straightforward. To ensure this, it is essential to conduct a comprehensive set of tests, including both automatic and manual evaluations.

Stage #4 in detail

We have included what tests are needed, and why, as well as your secure implementation to-do list.

Once all stakeholders have made their final design choices, the actual implementation of the software starts. At this stage, it is important to provide tools and processes that help ensure secure coding.

Part of the implementation is also to write test cases (for automatic and manual tests) for the quality assurance of the developed software. In this way, TeamViewer ensured that changes during the implementation are directly covered by the corresponding test case. To check whether the components are written by the developer’s work, TeamViewer uses unit tests already at the stage of implementation. Without a successful unit test, no developed software will be considered as done (as also stated in the DoD).

Secure Implementation in action — your to-do list

Offer code reviews
Prior to a release, your security expert(s) should be available to help with code reviews, in particular if your release will affect sensitive components of the overall solution. Make sure to document what components are regarded as security sensitive so it’s clear to developer teams when they will need a final code review.

Make unit tests part of the implementation
Before any implementation can be considered as done (according to the DoD), ensure that unit tests can pass successfully.

Stage #5 in a nutshell

During the verification stage you want to ensure that your software functions as intended and adheres to the security measurements you have built around it.

Stage #5 in detail

We look at what kind of tests you should be performing and how to tick them off your verification to-do list.

The verification stage provides tools that aim to verify that the implemented security measurements are functioning as expected. Basically, you need to test not only that the software is doing what you wanted it to do but also that the security mechanisms put in place are indeed protecting the solution efficiently etc.

As part of the final step prior to release, there is a code signing service that was built with security in mind at TeamViewer. It securely manages the signing of binaries prior to their release. This ensures that signing certificates are controlled and are not freely available in the build and development environments.

With the support of code scans, a list of all components used in software including versions and vendors is required. This is called a software bill of material (SBoM). A SBoM serves as a risk management tool by helping developers and IT teams identify and address potential security vulnerabilities in the software. Consequently, an SBoM is important to ensure that the software components used are secure and up to date. TeamViewer conducts a risk assessment with the support of all known components of a software and uses these components to map it against vulnerability databases to identify risks and to improve the tooling.

Security risks don’t just come from the outside of an organization. For this reason, TeamViewer uses internal dependencies scanning. Accurate inventories of software dependencies and ensuring to get notified for available patches also counts to successful protection and security.

Verification in action — your to-do list

Model attacks
Periodically review your applications architecture to identify attack surfaces and vectors that may not have been discovered during implementation. This is particularly efficient if the reviews are performed by a trusted partner, e.g., an external party.

Perform penetration testing and vulnerability assessments
Perform penetration tests on your entire product line. Again, it is recommended to have external parties perform these to make sure unforeseen vulnerabilities are detected efficiently.

Perform static code analysis
Static code analysis is a method of finding typical bugs that is done by examining the code without executing the program. The goal of static code analysis is to find coding and syntax errors and to provide various security checks that help to avoid some common vulnerabilities being introduced into the code.

Do a software composition analysis (SCA)
To manage and understand the components used in the software application, organizations should better use tools for software composition analysis. This method ensures that the components used in an application are secure, licensed properly, and free of known vulnerabilities. SCA tools scan an application’s dependencies and compare them to a database of known components. This database is constantly updated to include new and updated information on security vulnerabilities, licensing information, and other relevant data. The SCA discovers and helps to avoid supply chain attacks.

Stage #6 in a nutshell

With the tests completed it’s time for users to benefit from the software. To ensure a secure release, it’s important to use a hardened code signing service before it reaches the end user.

Stage #6 in detail

Tick off this one very important item on your secure release to-do list.

Once a newly developed piece of software has been thoroughly tested, it is time to release it so users can start benefiting from it.

Secure release in action — your to-do list

Use a hardened code signing service
As part of the final step prior to release, use a code signing service that was built with security in mind. Such a service securely manages the signing of binaries prior to their release. This ensures that the process of signing certificates is controlled and that these certificates are not freely available in the building and development environments.

Stage #7 in a nutshell

Even when you strictly follow each stage and test continuously, the threat of vulnerability is always present, and you need to be ready for it. To maintain security, you need a security incident response plan. As part of this, ensure that there is a clear reporting system in place so that those responding to incidents can effectively communicate their findings back to the wider team. Implementing a bug bounty team (more about in the fold out) is also a keen approach to catch and respond to vulnerabilities efficiently.

Stage #7 in detail

Tackle incidents effectively and efficiently by following your response to-do list.
You can test and test and test again, but occasionally, a vulnerability might make its way into a system. Even if this rarely happens, you need a very clear guideline for how to handle an issue if it arises.

The security incident response plan provides all templates, playbooks, and roles and responsibilities for handling security incidents related to TeamViewer products.

As part of this, dedicated members of the R&D team need to be in place not only to respond to incidents but to communicate their findings thereafter and ensure that they are implemented as security improvements.

If software is available for the user, it is important to follow up on the usage of the corresponding software. TeamViewer has a dedicated team to ensure safe and secure usage of TeamViewer application for all users. To ensure this user journey, TeamViewer is taking care of anti-fraud management and measures. This includes internal controls and investigations. Technologies such as machine learning and artificial intelligence (AI) are being used to improve the detection and prevention of fraudulent activities.

After a release, TeamViewer uses a security measure to protect the company’s brand and reputation. TeamViewer identifies and prevents unauthorized use of the company’s name, logo, or other branding elements. This includes monitoring for counterfeit products, phishing scams, and other forms of fraud that use the company’s branding to deceive consumers.

TeamViewer has specified information security events and incidents which will determine different types of responses and required resources. This classification consists of severity level and impact. This classification defines the following:

• if a release is blocked (Prio 1)
• if a release needs a hotfix after release as soon as possible (Prio 2)
• if a release needs fixes after the release in a specific timeframe (Prio 3)
• if a release can be done with minor findings (Prio 4)

TeamViewer continues to develop a standardized bulletin process for the reporting of security issues to the public. In addition, we are working on an advanced notification process for key customers.

TeamViewer has an established method for security researchers and partners to get in touch with them to disclose a vulnerability by the vulnerability disclosure program. TeamViewer can get the issue resolved and a fix published. If an external party reaches out to disclose a vulnerability, this will be done securely by a special platform or via PGP key.

Additionally, TeamViewer has a bug bounty program in place which can be reached through a platform provided by a trusted community. In this program, TeamViewer provides attractive bounties for discovering vulnerabilities. In this way, TeamViewer benefits from continuous testing, test diversity, the right resources, and detailed bug reporting.

Common vulnerabilities and exposures (CVE) numbering authorities are organizations responsible for assigning unique identification numbers to security vulnerabilities in software and other technology products. The purpose of these unique identification numbers is to provide a standardized method for referring to security vulnerabilities in a consistent manner. This makes it easier for stakeholders such as software vendors, security researchers, and consumers to communicate about and track the status of these vulnerabilities.

Since December 2022, TeamViewer has been authorized by the CVE program as a CVE numbering authority (CNA) and is responsible to assess and validate security vulnerabilities reported by software vendors. Through this program, TeamViewer ensures the security of software and technology products and helps to promote effective communication and collaboration among stakeholders, and to support the development of more secure software and technology products.

TeamViewer deals with vulnerabilities originating from different external sources. A big risk is here that the duration of mitigation or the length of time it takes to fix a vulnerability and hunters/researchers might disclose them publicly. To mitigate this risk, TeamViewer has internal service-level agreements (SLAs) for vulnerability remediation in place. Depending on the CVSS (common vulnerability scoring system) score, each corresponding issue will have a due date for mitigating or fixing the vulnerability for the impacted development team.

TeamViewer prepares for larger disruptions to the production environment by having a disaster recovery plan in place. This comprehensive plan and set of procedures outline how TeamViewer will respond to and recover its product from a significant IT or business interruption event such as neutral disaster, cyber-attack, power failure or any other unexpected event.

Response in action — your to-do list

Put an incident response plan in place
Your product security incident response plan should clearly describe and gather all templates, playbooks, roles, and responsibilities for handling security incidents related to your software.

Appoint a product security incident response team (PSIRT)
Create a dedicated team with representatives from the R&D department to respond to security incidents and make sure this team feeds their findings back into product security improvements.

Create a security bulletin process
Develop a standardized bulletin process for reporting security issues to the public. If you have the resources, you can develop a more advanced notification process for key customers.

Use resources for anti-fraud management
Anti-fraud management is becoming more and more important. For this reason, it will be beneficial for the safe and secure usage of the released software by controls and investigations. This could be done internally and/or externally.

Ensure brand exploit protection
The impact of a release for a company should not be covered by any reputational damage. Therefore, it is worthwhile to use brand exploit protection for this by using internal and/or external tools and knowledge.

Determine different types of responses and resources by a defined classification of findings
Severity and impact will define the responses and required resources for mitigating a vulnerability or fixing a bug. To be able to manage your risks and mitigation it is needed to set up and define a classification of vulnerabilities and findings and how to deal with it before the release will happen.

Enable responsible disclosure
Establish a method for security researchers and partners to get in touch with the relevant people at your company to disclose vulnerabilities they have discovered, so you can quickly resolve these and offer a patch.

Ensure security of software and technology products by using CVE databases or even becoming authorized as CVE numbering authority (CNA)
Always check if your software is affected by any known vulnerability by using vulnerability databases like e.g. CVE. This prevents an attacker using a known vulnerability to take advantage of to get to a cybersecurity breach and reduces the overall attack surfaces.

Put internal SLAs in place for vulnerability remediation in time
Nothing is worse than having a known vulnerability which will be disclosed because it was not fixed in the appropriate timeframe. To ensure such an issue will not happen to you, it is essential to put internal SLAs for vulnerability remediation in place which will manage the mitigation in affected teams in time to reduce risk for disclosure.

Support your business continuity management (BCM) by having a disaster recovery plan in place
The goal of a disaster recovery plan is to minimize the impact of an event on the organization’s critical operations and to ensure the availability of critical business functions as quickly as possible after the event. The disaster recovery plan typically includes the following components:

• Business impact analysis: A risk assessment of the organization’s critical business functions and the impact of an interruption on those functions.
• Recovery strategies: The methods and techniques for restoring critical systems and data after an event, including data backup and recovery, hardware and software replacement, and alternate processing site arrangements.
• Recovery teams: The identification of key personnel and their roles and responsibilities in the disaster recovery process.
• Communication plan: The procedures for communicating with stakeholders, including employees, customers, partners, and regulatory agencies, during and after an event.
• Testing and maintenance: Regular testing and maintenance of the disaster recovery plan to ensure its readiness and effectiveness.

The disaster recovery plan should be regularly reviewed, updated, and tested to ensure that it remains relevant and effective. This includes testing the plan’s processes, procedures, and technology to identify and address any gaps or weaknesses. The disaster recovery plan should also be communicated to all relevant stakeholders and made available to always authorized personnel.