CompTIA Security SY0-601 Exam: Basics of Secure Application Development, Deployment, and Automation

Objective: Summarize secure application development, deployment, and automation concepts.

Topics:
- application environment
- provisioning
- deprovisioning
- integrity measurement
- secure coding
- normalization
- stored procedure
- obfuscation
- camouflage
- code reuse
- dead code
- server-side validation
- client-side validation
- data exposure
- memory management
- automation
- scripting
- continuous integration and continuous delivery (CI/CD)
- Open Web Application Security Project (OWASP)
- elasticity
- scalability

Application Environment
Organizations that develop software tend to separate the process into various phases or application environments. Separate environments can also be used as a way to implement software application and operating system updates, especially in the test, staging, and production phases. For example, many organizations that have an application deployment life cycle test applications before deploying them. Separate environments are required because when applications are developed in production environments, programming mistakes can disable features, cause errors, or crash the application. Smaller organizations commonly use three environments, whereas larger organizations typically use four: development, testing, staging, and production.

Development and Testing
Organizations generally implement physical isolation or VLAN segmentation between the different environments. In the software development phase, the environment tends to be less restrictive than the testing environment for local rights because deeper levels of access might be required during development. When several developers are working on the same project, it is often advisable to have them work in a sandboxed or virtual environment so that code is not overwritten as it is developed. Versioning control software helps keep track of the software. Code gets checked out of a version control repository so that the system maintains a record of the code changes that occur. The development environment consolidates and validates the project team’s work so that it can be tested.
The test environment should be isolated from development. During the testing phase, the code is tested to determine how it interacts with a normal environment. The testing environment is a clean copy of the development environment used for integration testing. The testing environment also measures the performance characteristics of the software.
In a physical isolation environment, a firewall normally separates the environments from each other and the outside world. In VLAN segmentation, VLANs are often mapped into security zones. Traffic between zones must pass through a firewall that enforces the segmentation rules between the environments.
Testing and development environments often have lower security levels than do staging and production environments. Keeping these environments separate or isolated from each other provides segregation and prevents untested code from accidently being deployed. Development and testing environments often are deployed using a public cloud provider, and staging and production environments are deployed within an organization’s private network.
Quality assurance (QA) and testing processes directly affect code quality. The earlier defects in software are found, the easier and cheaper they are to fix. The benefits of implementing a sound QA and testing process far outweigh the associated costs. Providing quality software also builds a positive reputation for the organization and provides customers confidence in the products they are purchasing.

Staging and Production
A staging environment is often implemented to reduce the risk of introducing issues upon deployment in the production environment. A staging environment is primarily used to unit test the deployment of code. The staging environment should closely match the production environment, and it can also verify that the software runs under security settings. Although the staging environment should be closely matched to the production environment, using virtual machines (VMs) in the staging environment might be acceptable as long as the VMs are not measuring performance. The staging environment can also be used as a demonstration or training environment.
Developers should be able to deploy code to the staging environment. Care must be taken to be sure that version control is employed and that the proper version of the software is ported over. Staging basically provides one last opportunity to find and remove flaws or features that are not intended for production.
After code has been thoroughly tested and run through the staging environment, it can be deployed to production. The production environment is the final stage in the process and the actual “live” environment that will be running the code. The production environment should contain only applications that have already been developed, tested, and staged in the other environments. All pertinent security settings should apply, and access to the production environment should be limited to a few experienced developers.

Provisioning and Deprovisioning
Provisioning is the creation or updating of a resource. Deprovisioning is the removal of a resource. Provisioning and deprovisioning are part of organizational life cycle management and can affect a number of assets. Software provisioning and deprovisioning are generally automated processes in which software packages are made available to computers and users through a self-service portal. Provisioning can be integrated with other technologies as well, especially in cloud-based environments. For example, in one particular implementation, VMware used a private cloud based on a software-defined data center architecture to automate the provisioning process. The results included reduced application environment provisioning time, increased developer productivity, improved capacity, and significant cost savings.
Remember that provisioning is the creation or updating of a resource, and deprovisioning is the removal of a resource.

Integrity Measurement
When a program is run on a system, there is no indicator that shows how the code has affected the system on which the program is run. You do not know for sure that, after the program is run, the system is still exactly the same as it was beforehand. Because malware can infiltrate systems at a very low level, organizations need to be able to securely identify the software running on a system.
The way in which data about a system’s hardware, configuration settings, or software is collected is referred to as measurement. Integrity measurement uses attestation challenges from computed hashes of system or application information to obtain confidence in the trustworthiness and identity of a platform or software. The purpose of attestation is to gain confidence in the trustworthiness and identity of a platform or software. Integrity measurement uses attestation challenges to query the integrity status of software.
Integrity measurement is done through the Trusted Platform Module (TPM) at load time. When an executable loads, a hash function is used to fingerprint information. This information could be the executable itself, the executable along with its input data, or a sequence of related files. The hash values are then used to establish code identity to verifiers through attestation. In addition, these hash values can be used along with a feature called sealed storage, which uses cryptographically secure secrets so that only a specific application can open data files.
The TPM collects measurements, but it does not calculate the measurements and cannot take action on them.
Linux-based systems have the capability to implement the Integrity Measurement Architecture (IMA) through a kernel module. The IMA maintains a kernel trust chain. The IMA subsystem calculates the hash of a program before loading the program and validates the hash to a predefined list. When the system has a hardware TPM, the IMA maintains both a runtime measurement list and an aggregate integrity value over the list. This helps prevent undetectable software attacks.
Integrity measurement mechanisms that have been proposed and developed include those from the Trusted Computing Group (TCG). The TCG is responsible for publishing the transitive trust concept with hardware root of trust for TPM. The TCG has also defined the Core Root of Trust for Measurement (CRTM), which is the first action executed when booting. The CRTM measures the bootloader and sends the hash value to the TPM for storage in one of the Platform Configuration Registers (PCRs) before execution. After bootloader execution and before OS execution, the OS image is measured, and the value is stored in a PCR extension. This process continues for all loaded applications. When an attestation challenge occurs, the TPM signs a set of PCR values with an attestation identity key (AIK). The challenger decides on the integrity and trust status of the platform by comparing the returned result against known-good values.
Trust in all subsequent measurements is based on the integrity of the CRTM. If the CRTM is compromised, no further measurements can be trusted.

Change Management and Version Control
The software change management process is similar to the IT change management process. The primary function of change management is to control project or product changes so they meet both the defined scope and customer expectations. The capability to manage changes is a necessary component for quality in software products.
In organizations that closely align development and operations (for example, with DevOps), change management has a strong focus on responsiveness to requests for change and swift implementation of approved change requests. This is accomplished by using advanced automation and control tools to streamline the change- and release-management process. Different types of management are often consolidated into one pipeline.
Change management goes hand in hand with version control, and change management tools often are used to handle version control. Version control, or source control, is part of software configuration or change management that involves managing changes to collections of information. Version control involves tracking changes in the source code and providing software integrity during the development stages of the software development life cycle (SDLC). Strict version control prevents tampering with source code or executables.
Version control is done though a system, software tools, or applications that track software file changes and provide a way to manage changes to source code over time. Most version control systems use some form of distributed storage. For example, one tool might use one master server, and another tool might use a network of distributed servers.

Benefits of version control include the following:
- Historical data on changes to files
- Branching and merging capabilities
- Traceability
In a DevOps environment, version control is generally used as a predictor of performance because it can provide metrics for process improvement.

Secure Coding Techniques
Attacks against software vulnerabilities are becoming more sophisticated. Many times, a vendor misses a vulnerability and then, when it is discovered, does not address it for quite some time. The vendor decides how and when to patch a vulnerability. As a result, users have become increasingly concerned about the integrity, security, and reliability of commercial software. Software assurance describes vendor efforts to reduce vulnerabilities, improve resistance to attack, and protect the integrity of products. Software assurance is especially important in organizations where users require a high level of confidence that commercial software is as secure as possible. Secure software is achieved when it is created using best practices for secure software development.
The security of software code has come to the forefront in recent years, and coalitions have been formed to improve it. In addition, the industry offers certifications in software security. The Software Assurance Forum for Excellence in Code (SAFECode) works to identify and promote best practices for developing and delivering more secure and reliable software, hardware, and services. It was founded by EMC, Juniper Networks, Microsoft, SAP, and Symantec. Organizations such as (ISC)2 offer certifications specifically geared toward secure coding, such as the Certified Secure Software Lifecycle Professional (CSSLP). Secure software requires a number of stages, including design, coding, source code handling, and testing.
Given the ubiquity of web applications today, a notable organization is the Open Web Application Security Project (OWASP). Since its founding, the organization has annually published the OWASP Top 10 list of web application security risks, and now it also publishes an annual list for API security. OWASP is a nonprofit organization that provides a number of great resources for improving the security of software, and it hosts local chapters around the globe. See https://owasp.org for more information.
Security must be implemented in software from the very beginning. In the early design phase, potential threats to the application must be identified and addressed. Organizations must take into consideration ways to reduce the associated risks. These objectives can be accomplished in a variety of ways, such as through threat modeling and mitigation planning, which involves analyzing potential vulnerabilities and attack vectors from an attacker’s point of view. When the design is complete, the secure programming practices must be implemented. Secure coding involves inspecting an application’s source code to identify vulnerabilities created by coding errors.
Organizations should implement secure programming practices that reduce the frequency and severity of errors. Source code review should combine manual analysis and automated analysis tools.
Using automated tools along with manual review can reduce the vulnerabilities that might be missed by using only one method.
When the coding is done and the code has been reviewed, you must carefully handle the source code. Procedures for the secure handling of code include strict change management, tracking, and confidentiality protection of the code. To prevent malicious insiders from introducing vulnerabilities, only authorized persons should be permitted to view or modify the code. An additional measure for the protection of code is to protect systems and code repositories from unauthorized access. When development is outsourced, you should conduct internal design and code reviews to prevent malicious code from being introduced.
The final step in secure code development is testing. In the testing phase, particular attention should be given to validating that the security requirements were met and the design and coding specifications were followed. Testing processes can include applying testing techniques such as fuzzing and using a variety of inputs to identify possible buffer overflows or other vulnerabilities. Some software vendors submit their products for external testing in addition to doing internal testing because an unbiased independent test might uncover vulnerabilities that would not be detectable using internal processes. The secure code testing phase can include the black box, white box, or gray box testing methods.”
Fuzzing is software testing that provides invalid or unexpected testing data as an input to identify software exceptions, crashes, or other undesirable behavior.

Normalization
Applications often accept untrusted input strings and use techniques such as validation methods and input filtering. These methods are based on the strings’ character data and are similar to using a block list to explicitly prevent the characters from being submitted. Although they are not really sufficient for complete input validation and sanitization, these methods do provide some level of security. For example, an application might be programmed to forbid certain tags in input in order to mitigate cross-site scripting (XSS) vulnerabilities. When an application uses this type of method, after it is accepted, the input should be normalized before it is validated. Normalization is the conversion of data to its anticipated simplest known form. It provides assurance that all equivalent strings have unique binary representations. This is necessary because, in Unicode, the same string can have many different representations.
If software accepts data merely because strings can have different representations, then the application can accept malicious code. With normalization, when the input is validated, the malicious input is correctly identified.
Validating input before normalization allows attackers to bypass security mechanisms and execute malicious code.

Stored Procedures
Stored procedures are most often associated with databases and database queries. A stored procedure is a combination of precompiled SQL statements, stored in the database, that execute some task. The purpose of a stored procedure is to allow the acceptance of input parameters so that one procedure can be used by many clients using varied input data. This produces faster results and reduces network traffic.
Stored procedures can be used for security by encapsulating certain logic in server-side persistent modules. Client or user database communication is then restricted to use only server-side stored procedures. To increase security and reduce SQL injection vulnerabilities, data manipulation statements such as SELECT or DELETE have to go through the stored procedures before returning data. SQL injection vulnerabilities are reduced because stored procedures can be written so that the stored procedure has execute rights, without the client or user needing to have read/write permission on the underlying tables. Using stored procedures does not necessarily eliminate SQL injections, however: When dynamic SQL is allowed to be created inside a stored procedure, SQL injection can still occur.

Encryption, Obfuscation, and Camouflage
Encryption tends to be a catchall solution. When in doubt, encrypt. Encryption, obfuscation, and camouflage are used in the software development process to prevent software from being reverse engineered. These practices protect the trade secrets and intellectual property of organizations.
Encoding technologies have been developed to effectively hide executable program code in plain sight so the code does not have to be decrypted before it is run. This allows the software to run but not be reverse engineered.
Obfuscation, which has been used for a long time in interpreted languages, often involves shortening function and variable names and removing whitespace. The best way to see the prevalence of this technique is to view the source code of a web home page such as Google’s. When used in a malicious manner, obfuscation usually goes a step further and encrypts the underlying source code, which is then decrypted on the fly when the code is run.
Whereas obfuscation uses the process of hiding original data with random characters or data, camouflage replaces sensitive data with realistic fictional data.
Camouflage can also protect software from reverse engineering. Fake source code is created by modifying a piece of original source code. When an attacker analyzes the program, the attacker sees the fake code, but the program executes the original code when it is run.
Use of these techniques can affect the functionality of the software and programs. For example, if SQL Server objects, procedures, or functions are encrypted, the source cannot be retrieved from the SQL Server database.

Code Reuse and Dead Code
Code reuse is the practice of using existing software to build new software. A great deal of the code used in software development is reused to save time and development costs. Although code reuse is beneficial because much of the work has already been done, it can introduce security flaws and vulnerabilities into a product. Developers sometimes use vulnerable or non-patched versions of reused components even after vulnerabilities are made public and more secure versions are available. Much of this code comes from third parties and enables attackers to target one component vulnerability that many applications might have used. For example, with the OpenSSL Heartbleed and GNU Bash Shellshock attacks, libraries and frameworks that contained unpatched vulnerabilities were used in applications. Either the development team lacked due diligence in these cases, or a vulnerability was discovered in code that had previously been considered reliable.
To mitigate the effects of introducing vulnerabilities through code reuse, organizations must exercise due diligence, keep components patched, and continually strive to find reliable sources of code when creating new products.
Dead code is code contained in a program that can be executed but no longer provides a useful resulting action. Dead code often occurs when software requirements change, and developers have not taken the time to clean up the old code. As a common programming practice, dead code should be deleted or removed.
Know that code reuse is the practice of using existing software to build new software, and dead code is code contained in a program that can be executed but no longer provides a useful resulting action.
The execution of dead code can exhaust resources such as computation time and memory. In addition, an organization might face millions of dollars in costs if dead code is awakened. For example, in one organization, reuse of a flag that hadn’t been used in eight years triggered the execution of a version of the code that still had a dependency on the old flag. This misstep actually ended up bankrupting the organization.

Use of Third-Party Libraries and SDKs
As mentioned previously, much of the code used to create applications comes from third-party libraries. When using third-party libraries, an organization must exercise due diligence by keeping track of and implementing library updates and security measures. Most critical vulnerabilities in third-party libraries are disclosed in the Common Vulnerabilities and Exposures (CVE) system, making them quite visible for organizations to locate and track.
A software development kit (SDK) is a set of tools for creating applications using a certain software package. For example, if you are creating an Android application, you use the Android SDK. SDKs present the same security issues as third-party libraries. Known vulnerabilities in SDKs are also published via CVE. The biggest problem with vulnerabilities in third-party libraries and SDKs is that they can potentially affect millions of applications. This is why attackers have recently shifted efforts to this area.

Server-Side vs. Client-Side Execution and Validation
Client-side validation occurs when the data entered into a form is validated through a web page script via the user’s browser before the form is posted back to the originating server. Client-side validation is often used for convenience because it gives immediate feedback to the user if incorrect data is input. Client-side validation is an insecure form of validation in web applications because it places trust in the browser. This form of validation allows the client to execute validation and can be easily bypassed or altered; in addition, it allows the user to view the page code by using built-in browser capabilities. When an application accepts input from the client, the input should be validated on the server for type, length, and range.
Server-side validation occurs on the server where the application resides. Server-side validation helps protect against malicious attempts by a user to bypass validation or submit unsafe input information to the server. Server-side checks are more difficult to bypass than client-side checks and are a more secure form of input validation. Several techniques on the server side can improve validation, including identifying the acceptable data input type that is being passed from the client, defining the input format and type, building a validator routine for each input type, and situating the validator routines at the trust boundary of the application. A recommended approach is to initially perform client-side validation and then, after the input form has posted to the server, perform the validation a second time by using server-side validation.

Data Exposure
According to best practices, sensitive data should be encrypted at all times, including while in transit and at rest. Data exposure often occurs in applications because sensitive data such as credit card numbers, personal health information, and authentication credentials are not protected during transit. Other times, sensitive application data is stored unprotected, exposing the data.

Mitigation of data exposure should be addressed using an SDLC framework along with best practices. Addressing data exposure in both the requirements and design phases permits an organization to take a holistic approach to mitigation. Security best practices dictate that the following methods be included when building applications:
- Data validation
- Authentication and authorization
- Encryption
In particular, organizations should address the following three areas: exposed data that might be mistakenly uploaded, weak cryptography, and browser caching controls.

Proper Error Handling
Many of the software exploits that have emerged in the past few years have directly resulted from poor or incorrect input validation or mishandled exceptions. Common programming flaws include trusting input when designing an application and not performing proper exception checking in code. These practices allow attacks such as buffer overflows, format string vulnerabilities, and utilization of shell escape codes. To reduce these programming flaws, organizations should review practices related to authentication, authorization, logging and auditing, code dependencies, error message, and code commenting.
Authentication strength is vital to the security of an application. Instead of hard-coding credentials into an application or storing them in plaintext, it is a good practice to encrypt authentication credentials. This is especially important for a web application that uses cookies to store session and authentication information. In web applications or multilayered systems in which the identity is often propagated to other contexts, authorization control should form a strong link to the identity through the life cycle of the authenticated session. Logging and auditing should be designed to include configurable logging and auditing capabilities. This facilitates the flexibility of collecting detailed information when necessary. Using libraries from established vendors minimizes the risk of unknown vulnerabilities, especially when using object-oriented programming that relies on the use of third-party libraries.
Take care when programming error messages. Although error messages are important in identifying problems, they should not divulge specific system or application information. Attackers usually gather information before they try to break in to an application, and detailed error messages can give an attacker the information necessary to escalate an attack. Information output in error messages should be on a need-to-know basis. Exception handling should log an error and provide the user with a standard message. It is best practice to avoid using comments in public-viewable code that could reveal valuable information about the application or system, especially in web applications where the code and associated comments reside on the browser.

Proper Input Validation
Input validation tests whether an application properly handles input from a source outside the application that is destined for internal processing.
The most common result of improper input validation is buffer overflow exploitation. Additional types of input validation errors are format string and denial-of-service (DoS) exploits.
Application field input should always include a default value and character limitations to avoid these types of exploits. Software developers may overlook input validation, but it is very important. Testing code by sending varying amounts of both properly and improperly formatted data into the application helps determine whether the application is potentially vulnerable to exploits. Various methods can be used to test input validation, including automated testing, session management validation, race condition analysis, cryptographic analysis, and code coverage analysis.
An automated program can randomly perform input validation against the target, based on the program’s capability to handle input without any established criteria for external interfaces of the application. This means that any component of the application can be tested with randomly generated data without a set order or reason. Testing an application for session management vulnerabilities consists of attempting to modify any session state variables to evoke undesirable results from the application. Access can be gained to other communication channels through modified variables, leading to privilege escalation, loss of data confidentiality, and unauthorized access to resources. When time elapses between a security operation and the general function it applies to, a window of opportunity is created that might allow an attacker to circumvent security measures. This is known as a race condition. Testing for race conditions involves attempting to access the file between the time the application creates the file and when the application actually applies the security.
Sensitive data such as passwords and credit card information is frequently protected using cryptographic methods. Knowing what algorithm an application uses might make it possible to exploit its weaknesses. In addition, if strong encryption is used but the vendor implementation is incorrect, the data might not be properly protected; this could result in errors such as improper creation or storage of the cryptographic keys and key management. Code coverage analysis verifies that proper security measures are taken on all possible paths of code execution to ensure that no paths enable security to be bypassed and leave the system in a vulnerable state. This type of analysis can be resource intensive and should be done in stages during application development.

Code Signing
The most common example of code signing is drivers. For example, by default, Microsoft operating systems block the installation of unsigned drivers. Code signing consists of signing executables using a certificate-based digital signature. This is done to provide trustworthiness in the executable. Code signing proves the author’s identity and provides reasonable assurance that the code has not been tampered with since it was signed.
The two types of code signing certificates are organizational code signing certificates, which are issued to organizations, and individual code signing certificates, which identify independent developers. A certificate is issued by a certificate authority (CA) that validates the legitimacy of the issuer. If a nefarious person steals a legitimate certificate, that certificate can be used to sign malware and makes the program seem legitimate to unsuspecting users. For this reason, many cybercriminals and cybercriminal groups such as Suckfly are stealing certificates and using them in malicious attacks.

Memory Management
Memory management optimizes performance by assigning blocks of memory to various processes and programs. It ensures that sufficient memory is available for any currently running program or process. Memory management is used in all computing functions and plays an integral part in programming applications. Application memory management is based on allocation and recycling. Programs are written to request blocks of memory, and the allocator is used to assign a block to the program. When the program no longer needs the data in the assigned allocated memory blocks, the blocks can be reassigned.

Proper memory management in software development is imperative because many vulnerabilities take advantage of improper memory management techniques. For example, buffer overflow vulnerabilities are based on the capability to overflow the memory allocated for a variable. Suggestions for mitigating vulnerabilities such as buffer overflows include the following:
- Verify that the buffer is as large as specified.
- Use input and output control for data that is untrusted.
- Properly free allocated memory upon completion of the functions.
- Do not use known vulnerable functions.
- Clear sensitive information stored in memory to avoid unintentional disclosure.

Automation and Scripting
Resiliency and automation strategies help mitigate organizational risk. Resilience is the organizational capacity to continue acceptable levels of service when disruption to vital processes or systems occurs. Automation can range from basic scripting to automated collective action systems. It includes functions such as courses of action, continuous monitoring, and configuration validation.

Automation greatly increases an organization’s capability to detect and respond to threats. Automation systems or frameworks are used for courses of action and require the following:
- Interoperability and extensibility
- Built-in privacy protections
- Based on industry standards and international technical standards
- Capability to deal with system attack attempts
- Capability to effectively identify false positives (such as incorrectly identifying a vulnerability)

Automation systems combine machine learning with automation to respond to threats and maintain critical operations. Automated collection systems are meant to be resilient and secure because devices work together in near real time to anticipate and prevent attacks. These systems can be considered an extension of continuous monitoring, described in the next section.
Organizations have the option to automate individual areas as part of a holistic approach to automation. For example, an organization can automate infrastructure buildout to reduce the chance of security mistakes or can include automated security monitoring in system deployments as part of the configuration process.
Automation makes managing and securing the environment easier. However, when done incorrectly, automation breaks more than it fixes.
On a smaller scale, organizations can use scripting and vendor-provided tools for automated courses of action such as security and network tasks. Automation scripts for management and provisioning are run through command-line interfaces (CLIs) and APIs. Automated configuration and provisioning capabilities are already built in to devices from most major vendors. For example, Cisco IOS software provides embedded automation capabilities, and Windows PowerShell scripting is used to automate Windows administration and security tasks.
The purpose of continuous monitoring is to ensure that the processes are followed and enforced in order to detect organizational compliance and risk. In certain instances, such as to comply with industry regulations, continuous monitoring is required. For example, Payment Card Industry Data Security Standard (PCI DSS) compliance requires that an organization have well-defined processes in place to review and reassess security practices, even in highly dynamic business environments. FedRAMP, which focuses on cloud service providers (CSPs), requires that CSPs continuously monitor a cloud service offering to detect changes in the security posture of the system.
Tools often provide scripts to help with continuous monitoring. For example, Solar Winds maintains more than 100 predefined automation scripts in its script library. PowerShell can be used to implement continuous monitoring as well.
Configuration validation for organizations can be done through the Security Content Automation Protocol (SCAP), developed by the National Institute of Standards and Technology (NIST) to enable automated vulnerability management and policy compliance. Configuration Assessment as a Service (COAS) is a method developed in the European Union (EU) for automated validation and assessment of configuration settings over distributed environments. Configuration validation scripts can be written, depending on the target, and PowerShell can be used for configuration validation as well. For Windows machines, the Security Configuration and Analysis (SCA) snap-in works to validate configurations.
In addition, scripting languages such as Python can be used either alone or in combination with other scripts or tools. For example, Cisco DevNet has readily available scripts that leverage Cisco-provided Python libraries for device automation.

Secure DevOps
Development and operations (DevOps) originated in the recognition that organizational infrastructure should support development of the SDLC along with production capacity. Secure DevOps includes security in the SDLC, which was not always a major concern in developing software applications. When the topic was initially introduced, software developers had a negative reaction because it meant greater programming effort and delays in development and release cycles. The evolution of secure DevOps has produced some best practices for increased security of developed applications, including the following:
- Address security concerns at the beginning of a project.
- Reduce faults by standardizing the integration cycle.
- Add automated security testing techniques.

From a secure DevOps perspective, software should be secure and resilient. Developers should be proficient with tools and thought processes to develop software that can withstand attacks and continue to function instead of ones that only seek to prevent attacks. These tools offer more flexibility in mitigating attack risks. A secure SDLC requires an organization to focus on practices such as security automation, continuous integration, and infrastructure as code. DevOps offers the following benefits:
- Speed
- Rapid delivery
- Reliability
- Scalability
- Increased collaboration
- Built-in security

A main DevOps concept is continuous integration and continuous delivery (CI/CD). 


The DevOps life cycle

The CI/CD process is based on automated configuration and deployment scripts. Automated processes are critical to ensure that software operates as intended.
Continuous integration is the process in which the source code updates from all developers working on the same project are continually monitored and merged from a central repository. The repository is updated when a new commit or permanent change is detected. Software builds are triggered by every commit to the repository. CI helps avoid code merging conflicts that can arise when developers keep a working local copy of a software project for a long period of time.
The CI process is automated. A centralized server continually pulls in new source code changes as they are committed by developers. It then builds the software application and runs unit test suites for the project. When a process fails, the CI server fails the build and immediately notifies the project team of the failure.
CI servers are also called build servers because of their main function. A CI server compiles, builds, and tests each new version of code committed to the central repository without user interaction.
All members of the team are notified when code in the repository fails. This prevents team productivity loss by limiting the chance of merge issues and rework due to a broken codebase.
Continuous delivery automates code changes and testing and prepares the code to be delivered or deployed into test or production after the build stage. CD is associated with the test and release stages, and it allows the code to be manually triggered for release as desired or to be automatically deployed once the code has passed all tests.
While CD ensures that new secure applications and features are released efficiently and quickly, the operation and monitoring stages provide for continuous feedback. This feedback helps provide continuous validation of existing code and ensures that a better product is developed more quickly.
DevOps includes extra rigor and testing in order to foster a more secure environment. Automation frameworks such as Chef and Puppet are already used for IT infrastructure. Continuous delivery for secure code using security automation is similar to the automation of IT infrastructure.

Scripting and automation are a large part of DevOps, especially security. Security testing can be automated so that security concerns are designed into systems at the beginning of the process and then are continually checked as part of the software development process. These are the primary benefits of security automation:
- A more holistic approach to security because it is part of the build process
- Proactive scanning for common vulnerabilities throughout the entire process
- An available list of version control security checks with deployments
Security automation in the life cycle provides more secure, higher-quality code, at a faster rate.

Scalability and Elasticity
Although they are somewhat related, scalability and elasticity are two different concepts. Scalability is the capacity to expand the amount of production from the current infrastructure without negatively impacting performance. Scalability issues can cause failures in many areas, such as systems, applications, networks, and businesses.
Scalability can refer to systems or software applications and can be vertical or horizontal. Vertical scalability refers to the capability to scale up within a system; horizontal scalability refers to scaling linearly or scaling out to multiple systems. Applications are generally built with the capability to scale either vertically or horizontally so that lack of resources does not affect performance.
Scalability can involve the capacity to decrease as well as increase services or resources.
Elasticity is the capacity to dynamically expand or reduce infrastructure resources by autonomously adjusting to workload changes to maximize resources. Elasticity involves the capability for rapid, automatic, and elastic provisioning of resources to quickly scale out as well as the capability to be rapidly released to quickly scale in. Because elasticity is used in scale-out solutions, allowing resources to be dynamically added or removed, it results in infrastructure costs savings. This is particularly useful when dealing with virtualized environments, where host availability is a concern. With elasticity, resources can be purchased as needed based on timeframe, platform, or operating system.
Elasticity is most often found in cloud environments, where resources can be purchased for a short period of time based on demand and then deleted when no longer needed.
Organizations that have cyclical business periods often choose elastic options to reduce costs and administrative overhead. Security challenges in an elastic model include enforcing proper configuration, change management, and adequate administrative separation between virtual customer environments.
The main difference between elasticity and scalability has to do with resources. Scalability is based on the capability to handle the changing needs of a system, process, or application within the confines of the current resources. Elasticity is the capability to expand and reduce resources as needed at any given point in time.

Quiz:

1. Your team wants to use automation in the development process to help identify vulnerabilities that have been incorrectly identified before now. Which of the following best describes this type of mistaken identification? A. Identity theft B. False positive C. False negative D. Identity provider

2. Your organization’s compute needs are relatively the same throughout the year except for the two months leading up to a holiday. The board of directors is interested in how the organization can handle this additional capacity for this time period without incurring unnecessary costs the rest of the year. Which of the following best describes the board’s request? A. Elasticity B. Scripting C. Continuous integration D. Scalability

3. Your organization has been moving new applications from the testing environment directly to production, but lately there have been many issues. You have been asked to help mitigate these issues. Which of the following are the most appropriate? (Select two.) A. Move the code to both production environments to troubleshoot on one in case the other fails. B. Set up a parallel production environment. C. Set up a staging environment to closely match the production environment. D. Move the code to staging prior to moving it to production.

4. Your organization’s development team wants to protect trade secrets and intellectual property. What should the team implement during the software development process to prevent software from being reverse engineered? A. Normalization B. Stored procedures C. Obfuscation and camouflage D. Automation and scripting

Answer 1: B. A false positive is a result that incorrectly indicates that a particular condition, such as a vulnerability, is present. Answer C is incorrect as a false negative is not identified but is missed. Answers A and D are incorrect and refer to the use of someone else’s identity and a system that manages identity information, respectively.
Answer 2: A. Elasticity is the capacity to dynamically expand or reduce infrastructure resources by adjusting workloads to maximize resources. Answer B is incorrect as this is not the most specific answer. Scripting refers to automation, which elastic capabilities are likely to require. Answer C is incorrect. Continuous integration refers to the development process of continuous monitoring and merging. Answer D, while closely related to elasticity, is incorrect, as scalability refers to the ability to expand the amount of production from the current infrastructure without negatively impacting performance.
Answer 3: C and D. A staging environment is often implemented to reduce the risk of introducing issues upon deployment into the production environment. The code will be moved to production after being moved to staging. Answers A and B are incorrect. This would not be done in the application development process and is more akin to providing for redundancy.
Answer 4: C. Obfuscation, camouflage, and encryption are all often used in the software development process to prevent software from being reverse engineered. These practices protect the trade secrets and intellectual property of an organization. Answer A is incorrect. Normalization is the conversion of data to its anticipated, or “normal,” value. Answer B is incorrect because stored procedures are combinations of precompiled SQL statements, stored in a database, that execute some task. Answer D is incorrect because automation and scripting greatly increase an organization’s capability to detect and respond to threats. They combine machine learning with automation to respond to threats and maintain critical operations.