The CA Secure Software Development Lifecycle (SSDLC) and security-related best practices described in this document are designed to help our developers build more secure software and address security requirements throughout the product development cycle. Key aspects described below include education, architectural risk assessment, code analysis, penetration testing, and continuous tracking of known vulnerabilities and attack vectors.

CA Technologies Secure Development Best Practices

CA product development operates under a detailed internal Product Security Procedure which provides guidelines and objectives for secure development of our products. The procedure identifies requirements for security standards and provides strategies and tactics for implementing security during each phase of a product’s development lifecycle.

Responsibility for managing product security is not limited to the product teams. The Security Champions, the central SSDLC owners and the CA Product Security Incident Response Team (CA PSIRT) work with product development and 3^rd party security consultants on the identification, reporting and remediation of vulnerabilities associated with our products. In addition, educational courses and other resources are available to assist CA developers with secure coding.

How We Strengthen Security at Each Phase in the Development Lifecycle

SAFECode states, in its “Principles for Software Assurance Assessment” that “software assurance assessment should primarily focus on the secure software development process and its application to the product being assessed, while taking into consideration the context of a product’s intended operating environment. There is no single practice, tool, or checklist that acts as a silver bullet and guarantees better software assurance. Rather, the efficacy and efficiency of software security practices and tools varies based on how they are applied and whether they are implemented as part of a holistic software development process within each unique organization.”

In other words, efficient software assurance cannot be achieved by a single practice, tool or checklist; rather it is the result of a comprehensive secure software engineering process that spans all parts of development from early planning through end of life. It is also important to realize that, even within a single company and associated SSDLC, there is no one-size-fits-all approach. The SSDLC must be firm in its approach to security but flexible enough in its application to accommodate variations in a number of factors, including different technologies in use and the risk profile of the applications in question.

In simplest terms, a product’s lifecycle can be divided into the seven phases of Plan, Code, Build, Test, Release, Deploy and Operate:

Over the course of its lifecycle, a product will often repeatedly move through each of these phases. In an agile environment, each sprint typically includes aspects of all or most of these steps compressed into a shortened cycle where product development doesn’t follow a straight flow. Rather, the sprint contains frequent iterations of parts of this flow on a weekly or even daily basis.  However, this lifecycle flow is still a good model to which Security related activities can be anchored. Underlying these phases are basic foundational, cross organizational services.

FOUNDATION

A successful security program requires a strong internal security support organization that manages and provides a foundation for the SSDLC, including collecting and sharing knowledge and experiences across the organization, which is managed by central SSDLC and PSIRT owners working together with Security Champions supporting various business units. These teams work together to set the internal standards for security and assists product teams during the software development life cycle. The team(s) also works closely with Support and Broadcom IT to better ensure we have comprehensive coverage available throughout the product life cycle.

The SSDLC Owner defines the SSDLC for CA and is independent from the product teams. The SSDLC Owners responsibilities include maintaining procedures, ensuring tools and services support the SSDLC, and in partnership with Security Champions and 3^rd Party Security consultants act as an independent body to help validate the security of CA products. Broadcom’s internal development procedures include guidelines and requirements on what, when and how security activities should take place. These include activities for all phases described below, and speak to items such as Training, Coding Guidelines, Architectural Risk Analysis, Code Analysis, Penetration Testing, as well as Vulnerability Response. When applicable, they also include examples and template artifacts that the product teams can use to assist in their development activities. The SSDLC Owners actively participates in and/or closely monitors a variety of standards, industry groups and industry best practices (e.g., ISO27034, SAFECode, OWASP, BSIMM) to better understand how we can enhance our secure coding practices.

While the SSDLC Owners, Security Champions and 3^rd Party Consultants plays important roles as independent internal and external consultants and to help verify a product’s security, it is critical that everyone involved in product development is engaged in, and has appropriate knowledge of, secure development practices, and shares information to enhance the process. The SSDLC Owners update our internal guidance, training and best practices to continuously enhance the information provided to the development organization. To simplify this process, CA has an Internal Security Portal where current information is available, and cross organization collaboration with Security Champions. We also have channels where employees are welcome to share security related information or ask questions. The SSDLC Owners, the PSIRT and the Security Champions act as a virtual security special interest group, that ensures all products go through appropriate SSDLC steps and also share information on their experiences with complex issues and how the process can be further enhanced.

PLAN

We strongly believe that by focusing on security from the beginning, and appropriately planning and designing the solution with security in mind, we can develop products that are more secure and we can bring them to market more quickly. This includes ensuring that all teams have access to appropriate security training as well as comprehensive programs of role-based and web-based training spanning various areas, technologies, risks and tools.

During the planning phase, product teams often create an initial mapping of privacy and security requirements applicable to a given solution. Considerations include the type of data that will be handled by the solution, how and where the solution will be implemented, and industry requirements. Having checklists and central guidance from the central SSDLC Owners helps in planning and implementing appropriate levels of controls for data protection.

Based on the risk profile, the target market, and the development stage of the product, an Architectural Risk Analysis (also called Threat Modelling) can help identify design level issues or threats in advance of implementation to help address flaws before coding begins.

Finally, this is also the appropriate time for the product team to register included third-party components, which helps ensure legal licensing compliance and provides an opportunity for a risk based assessment of the components.

CODE

During the Code phase, developers can take advantage of static application security testing tools (SAST) which focus on detecting security issues while the code is being written. This includes deprecated/unsafe functions as well as more complex issues that may require analyzing Data Flow, Semantic, Control Flow, Configuration and Structural issues. By identifying many types of issues including OWASP Top 10 vulnerabilities and CWE/SANS-Top25 Programming Errors during coding, the developer can more quickly address the issue, learn from the findings, and better understand how to write secure code and/or identify the need for additional training.

Depending on the product’s risk profile, we may also perform Peer Code Review where another senior developer, familiar with the code, secure coding practices and the expected functionality of the solution, reviews the code.

Finally, the product teams determine whether vulnerabilities in a third-party component affect the product. Automated scanners and procedures assist in identifying if the product team chooses to upgrade or substitute the component, the bill of materials is adjusted and the new component or version is included in regular and ongoing vulnerability tracking.

BUILD

A formal system build is created on a regular basis, and the code base typically undergoes an audit using the same static application security testing tools used on the developer’s workstation during the CODE phase. This helps ensure that we catch issues, and provides us with another level of verification.

During the build process, we have procedures to initiate code integrity tracking which creates unique fingerprints for the build, and links it to the source code, the bill of materials and the system that was used to create the build. This allows us to better ensure that the code hasn’t been tampered with after the build, and provides further confirmation that we know exactly what went into the build.

TEST

When the various builds are ready to be integrated into a solution, a more complete system test is initiated. This system test can be repeated on a regular basis throughout the development lifecycle. The product team is able to work with the SSDLC owner and Security Champions to assess potential attack surfaces and to set up automatic Penetration Testing that can be scheduled to regularly scan the application for weaknesses. 

In addition to the tool based approach, the System Test team can leverage the experience and the training they received during the planning phase to set up automatic and manual testing for the solution. These test plans depend on a variety of factors, and may include tests derived from both internal procedures and industry best practices such as SAFECode Fundamental Practices, OWASP Testing Guide, etc. This can include low level details such as testing of edge cases and boundary conditions based on the architecture in use as well as higher level requirements such as proper encryption of Personally Identifiable Information at rest and in transit, using least privilege, et cetera. Test cases are often a combination of verification of expected behavior as well as negative requirements where carefully selected data helps the auditors verify how the application handles edge cases.

RELEASE

Before a product is generally available, its risk profile is assessed, and, based on this assessment, high risk products may receive more advanced penetration testing, which is a combination of automatic and manual tests performed by auditors. These tests are performed in an environment built using the planned template architecture and configured according to documented best practices. The tests may include multiple weeks of testing various security aspects of the solution, interviews with developers and architects, manual penetration testing, scans by penetration testing tools, fuzz testing, as well as automated scans of the infrastructure and known/common vulnerabilities in third-party components and their configuration.

Identified vulnerabilities are tracked in a central defect tracking system together with an associated risk rating (Critical/High/Medium/Low + CVSS score), and are not approved as remediated until a security expert has performed a Post Fix validation.

Finally, before any product is released, Antivirus/Antimalware scanning is performed on the final master media.

DEPLOY

For traditional distributed or mainframe on-premise solutions, the DEPLOY phase is typically performed by the client or professional services. However, for SaaS solutions, this step is usually performed by Broadcom.

During this phase for SaaS, a test environment is generally scripted to be identical to the planned deployed solution, and a final set of Application Penetration Tests as well as Infrastructure and Configuration Management Tests can be performed to help ensure nothing has changed and that previously identified vulnerabilities are resolved.

OPERATE

Through the remainder of the product’s lifecycle until it is no longer supported, the product team works with a number of central functions to help ensure that the product is properly managed from a security perspective. This can include continuous scanning for vulnerabilities in our native code and in third-party components. This can also include managing and remediation of vulnerabilities reported to us by clients or security researchers, issues identified by development after the release, or by automated tools and processes to identify vulnerability reports concerning third-party components.

We have a set of comprehensive incident response and vulnerability handling policies and works closely with leading vulnerability research entities to actively monitor a large number of sources for vulnerability information, including vendor websites, public mailing lists, and other security-related websites.

To assist us in addressing vulnerability information, we have a set of policies and procedures, including comprehensive internal vulnerability handling procedures. In accordance with those procedures, we have vulnerability experts and Security Champions who focus on complex vulnerability issues, and work with Technical Support, Sustaining Engineering, Development and Product Management to help ensure that each vulnerability issue is properly resolved. To address validated vulnerability issues, we post security notices, patches, and remediation information on the Support website. Additionally, we may disseminate security notices and advisories to customer email lists, public mailing lists (mentioned above), and to various vulnerability-related organizations such as CERT and Mitre CVE.

FAQs

Frequently Asked Questions and guidance for the secure development processes of the Agile Operations Division