devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • What GitHub’s 2FA Mandate Means for Devs Everywhere

    What GitHub’s 2FA Mandate Means for Devs Everywhere

    Multifactor authentication (MFA) is becoming increasingly standard within software development organizations, with GitHub recently announcing that two-factor authentication (2FA) will be mandatory for all code contributors by the end of 2023.

    This is a smart move. In recent years, bad actors have frequently initiated attacks by accessing source code through the use of stolen developer credentials. Once inside, they quickly penetrate organizations’ entire code repositories and elevate access to company-wide systems. This was the case with the 2021 SolarWinds compromise that ultimately jeopardized federal agencies, corporations and governmental institutions.

    But for some developers with lofty goals and concentrated timelines, MFA is an extra step that has the potential to slow them down. As organizations continue to implement MFA and other foundational security controls, they may face pushback—but they shouldn’t be deterred. MFA is a critical attack barrier that improves individual protections and can contribute to tightened source code security. 

    If organizations approach implementation thoughtfully, they can lay the foundation for subsequent security controls—and build credibility among their users and within the larger development community.

    The Risks of Lax Individual Developer Security

    Organizations’ source code typically powers a host of upstream programs and products, so it’s valuable for bad actors to launch attacks by infiltrating their repositories. Attackers can also hide malware in source code that can be escalated to breach entire systems and third-party organizations. This risk is heightened by the fact that many companies rely solely on antivirus scans and other surface-level monitoring tools to flag source code vulnerabilities instead of combining them with dynamic testing and penetration testing.

    Attackers typically gain access to source code through stolen developer credentials. While single authentication systems—i.e., usernames and passwords—are the easiest to compromise, MFA creates an additional barrier that’s more difficult for attackers to overcome. While this tool does create additional friction in the development process, it’s worth the extra step. Even for hobbyist or open source developers, compromised source code can cause larger repercussions that put other developers at risk. When it comes to cyberattacks, it’s best to assume any entity is a potential target. 

    Beyond individual security, MFA and other foundational controls are critical to safeguarding organizational reputations and adhering to legal privacy standards. By 2023, 65% of the global population will have personal data covered by privacy regulations. Security measures that protect authentication credentials will become even more important in the coming years, especially for organizations producing source code that powers consumer-facing products and programs. With an intentional approach to implementation, MFA can help mitigate potential source code attacks—and form the basis of comprehensive security programs.

    Four Steps to Successful MFA Implementation 

    The benefits of MFA far outweigh the cost of user friction and developer pushback. Get the most out of this authentication technology by following these four steps to implementation.  

    1. Start small and build credibility. Approach implementation gradually to help developers understand MFA’s value. Successful implementation will give your leadership and security teams credibility for future security initiatives, and it will improve processes for security integration into your larger software development life cycle.  
    2. Examine your security program’s value chain. Implementing foundational security controls like MFA provides an opportunity to examine your security program’s entire value chain. Take time to look for potential vulnerabilities beyond your source code repository and flag areas within your development lifecycle that may create risk.
    3. Layer subsequent security controls. With MFA under your belt, build up your security program with other tools and controls—like dynamic and penetration testing, source code scanning, software composition analysis (SCA) and vulnerability management. The more security tools you layer, the harder you make it for attackers to succeed. 
    4. Plan for continuous optimization. Attackers will devise more ways to thwart MFA as more organizations mandate it. For example, the popularity of using SMS as a second form of authentication declined when attackers developed methods to gain control of mobile phones. To keep up with evolving attacker behaviors, continuously optimize your MFA technology and subsequent security controls. 

    MFA Will Become the Industry Standard

    As bad actors evolve attack methods and privacy regulations strengthen, MFA will undoubtedly become an industry standard for protecting source code repositories. 

    To stay ahead of the curve, focus on the concept of MFA throughout your network by ensuring it protects every system entry point. This extra step is an easy price to pay for improved source code protection—and ultimately safeguards every asset, product and program your code powers. Thoughtfully implementing MFA can lay the foundation for comprehensive source code protection.

  • Four Secure Coding Best Practices for Mobile Apps

    Four Secure Coding Best Practices for Mobile Apps

    Mobile apps have become the primary point of innovation for many companies, and skilled mobile developers are in high demand. The business asks developers to innovate fast using the latest smartphone features and capabilities to drive high download rates, wow their users, capture customers and grow their business. Dev teams facing constant pressure to move faster may push security to the back burner, focusing on required features and delivery dates the business demands. However, many dev teams have figured out how to innovate faster with security built in by ensuring that devs understand key security requirements and coding best practices. Working with hundreds of development teams on securing thousands of mobile apps, we found four common areas of security failure that can be addressed easily.

    Use SSL via HTTPS

    Mobile app devs may instinctually use Hypertext Transfer Protocol (HTTP) for network communications. However, HTTP puts private user information out in the open for threat actors to intercept. Developers can fix this common mistake by using HTTPS instead, which encrypts data sent to and from servers via industry-standard SSL. Android developers can use the available NetworkSecurityConfig file to set up a predetermined configuration for all network connections made within the app or manually incorporate HTTPS. iOS developers can use App Transport Security (ATS) as the default feature that enforces secure communications in iOS apps and prevents any insecure connections between the mobile app and the server from being completed.

    Validate the Contents of the Certificate

    Certificates add an additional layer of security to HTTPS connections by enforcing additional validations when performing a connection. Certificates include the certificate authority (CA) that signed it and the list of hostnames known or accepted by the application. Apps that validate these components when performing connections with the server significantly reduce the risk of a man-in-the-middle (MITM) attack that can steal credentials and sensitive data.

    To verify a certificate has been issued by a valid CA, Android developers can reference the preconfigured list of CAs included on devices running the mobile operating system. Android developers can implement native classes such as HostnameVerifier to achieve proper hostname verification within their app.

    iOS developers can leverage ATS that provides built-in validation, or use methods in the NSURLSession class to manually code these instead.

    Avoid Hardcoding Resources of a Mobile App

    Attackers often use hardcoded info within the source code of a mobile app to take advantage of users. For instance, attackers can use credentials stored within app files to gain access to a user account. Attackers can also find hardcoded API keys or URLs to gather private data or take over an app entirely. Mobile app developers can prevent these areas from being compromised by not hardcoding keys, passwords and URLs into the source code. Encrypting transport and decrypting data on the backend also adds an extra layer of security.

    Use the Latest Cryptography to Protect Mobile Users

    Outdated cryptography algorithms like SHA-2, RC4 and DES allow attackers to easily break a seemingly secure mobile app. Using older algorithms may also make a mobile app non-compliant with industry regulations leaving an organization at risk of fines or legal jeopardy. Devs can avoid this problem for Android and iOS mobile apps by using the latest cryptography algorithms available, selecting those that are suitable for a specific app scenario. When signing your binary before publishing it to the store, use keys with a length of at least 2048 bits (preferably 4096 bits), and on Android use SecureRandom or SecRandomCopyBytes on iOS when generating random values for cryptographic implementations. Android devs can leverage the Keystore class and iOS devs can leverage Keychain services to store highly sensitive data. Devs should avoid insecure modes of operation, improperly generated cryptographic keys and initialization vectors (IVs) to guarantee that the information that is encrypted cannot be decrypted by a malicious actor.

    Today’s mobile app users need confidence that mobile apps are built with security in mind. While building innovative mobile apps, developers have a responsibility to learn a practical set of secure coding best practices to protect their users (and their businesses).

  • MLOps Vs. DevOps: What’s the Difference?

    MLOps Vs. DevOps: What’s the Difference?

    Machine learning operations, or MLOps for short, is a key aspect of machine learning (ML) engineering that focuses on simplifying and accelerating the process of delivering ML models to production and maintaining and monitoring them. MLOps involves collaboration between different teams including data scientists, DevOps engineers, IT specialists and others.

    MLOps can help organizations create and improve the quality of their AI and machine learning solutions. Adopting MLOps allows machine learning engineers and data scientists to collaborate to improve model performance by implementing continuous integration and continuous deployment (CI/CD) practices. It accelerates the ML model development process by incorporating the appropriate monitoring, governance, and validation of ML models.

    What Is DevOps?

    DevOps combines the concepts of development and operations to describe a collaborative approach to performing the tasks usually associated with separate application development and IT operations teams. DevOps, in its broadest sense, is a philosophy that encourages improved communication and cooperation between these (and other) teams within an organization. 

    In its narrowest sense, DevOps refers to adopting practices that enable the deployment and maintenance of iterative application development, automation, and programmable infrastructure. It also includes changes in the workplace culture, like trust-building and bonding between developers, system administrators and other team members. DevOps aligns technology with business objectives and can transform the software delivery chain, job functions, services, tools and best practices.

    MLOps Vs. DevOps: Key Differences

    Here are some of the main differences between MLOps and traditional DevOps.

    Development

    The concept of development refers to different things in each model, with a slightly different CI/CD pipeline.

    DevOps:

    • Usually, the code creates an interface or application. 
    • The code is wrapped into an executable or artifact before being deployed and tested with a set of checks. 
    • Ideally, this automated cycle will continue until the final product is ready.

    MLOps:

    • The code enables the team to build or train machine learning models. 
    • The output artifacts include serialized files that can receive data inputs to generate inferences. 
    • Validation involves checking the trained model’s performance based on the test data.
    • This cycle should also continue until the model reaches a specified performance threshold.

    Version Control

    DevOps:

    • Version control typically only tracks changes to code and artifacts.
    • There are few metrics to track.

    MLOps: 

    • MLOps pipelines usually have more factors to track. Building and training an ML model involves an iterative experimentation cycle, requiring tracking of various metrics and components for each experiment (essential for later audits). 
    • Additional components to track include training datasets, model building code and model artifacts. 
    • Metrics include hyperparameters and model performance indicators, such as error rates.

    Reusability

    DevOps:

    • DevOps pipelines focus on repeatable processes.
    • Teams can mix and match processes without following a specific workflow.

    MLOps: 

    • MLOps pipelines repeatedly apply the same workflows. The common framework across projects helps improve consistency and allows teams to progress faster because they start with familiar processes. 
    • Project templates offer structure, enabling customization to address the unique requirements of each use case.
    • Uses centralized data management to consolidate the organization’s data to accelerate the discovery and training processes. Common approaches to centralization include a single source of truth and data warehouses.  

    Continuous Monitoring

    Monitoring is essential for both DevOps and MLOps, but for slightly different reasons.

    DevOps:

    • Site reliability engineering (SRE) has been trending over the past few years, emphasizing the need for monitoring software from development through to production deployment. 
    • The software does not degrade in the way an ML model does. 

    MLOps:

    • Machine learning models can degrade quickly, requiring constant monitoring and updating.
    • Conditions in the production environment affect the model’s accuracy. After deployment to production, the model starts generating predictions based on new data from the real world. This data is constantly changing and adapting, reducing model performance. 
    • MLOps ensures that algorithms remain production-ready by incorporating procedures to facilitate continuous monitoring and model retraining.

    Infrastructure

    DevOps and MLOps both rely heavily on cloud technology, but have different operational requirements.

    DevOps relies on infrastructure such as:

    • Infrastructure-as-code (IaC)
    • Build servers
    • CI/CD automation tools

    MLOps relies on infrastructure such as:

    • Deep learning and machine learning frameworks
    • Cloud storage for large datasets
    • GPUs for deep learning and computationally-intensive ML models

    DevOps and MLOps Trends

    Here are some of the major trends driving the development of DevOps and MLOps.

    GitOps

    A new evolution of the DevOps workflow, GitOps is a new paradigm for controlling and automating infrastructure. A Kubernetes-oriented paradigm enables developers and operations teams to manage Kubernetes clusters and deliver containerized applications using Git. Implementing Git workflows for operations and development teams allows developers to leverage Git pull requests to manage software deployments and infrastructure.

    GitOps incorporates existing development tools to manage cloud-native and cluster-based applications with CI/CD. It automatically deploys, monitors, and maintains cloud-native applications using a Git repository as the single source of truth.

    GitOps is a way to implement and maintain clusters in Kubernetes. Continuous delivery and deployment allow developers to build, test, and deploy software faster through incremental releases. Kubernetes continuous integration and runtime pipelines must be able to read and write files, update container repositories, and load containers from Git. GitOps helps businesses manage their infrastructure with version control, real-time monitoring, and alerting of configuration changes.

    Synthetic Data

    Synthetic data is any information generated artificially instead of collected from real events. Algorithms generate synthetic data for use as a replacement for operational and production test datasets. Synthetic datasets are also useful for validating mathematical models and training machine learning models.

    Benefits of synthetic data include:

    • Minimizing the constraints associated with using sensitive and regulated data.
    • Customizing data to specific requirements and conditions not available in real-world data.
    • Generating data for testing software quality and performance for DevOps teams.

    Codeless Machine Learning and AI

    Machine learning often involves computer code to set up and process model training, but this is not always the case. Codeless machine learning is a programming approach that eliminates the need for ML applications to go through time-consuming processes.

    Codeless ML eliminates the need for experts to develop system software. It is also simpler and cheaper to deploy and implement. Using drag-and-drop input during machine learning processes can simplify training efforts in the following ways:

    • Evaluating results.
    • Dragging and dropping training data.
    • Creating predictive reports.
    • Using plain-text queries.

    Codeless ML gives developers easy access to machine learning applications, but it is no substitute for an advanced, nuanced project. This approach is suitable for small businesses that lack the capital to maintain an in-house data science team.

    TinyML 

    TinyML is a new approach to machine learning and AI model development. It involves running models on devices with hardware restraints, such as microcontrollers powering smart vehicles, refrigerators and electric meters. This strategy is the best fit for these use cases because it speeds up the algorithm—there is no need for the data to go back and forth to a server. It is especially important on large servers and can speed up the entire ML development process.

    Running TinyML programs on an IoT edge device has many benefits:

    • Lower energy consumption.
    • Reduced latency.
    • User privacy guarantees.
    • Reduced bandwidth requirements.

    Using TinyML offers greater privacy because the computation process is entirely local. It consumes less power and bandwidth, resulting in lower latency because it doesn’t require sending data to a central location for processing. Industries that are taking advantage of this innovation include agriculture and healthcare. They typically use IoT devices embedded with a TinyML algorithm to monitor and predict real-world events using collected data.

    Conclusion

    In this article I covered the key differences between MLOps and DevOps:

    • Development—DevOps pipelines focus on developing a new version of a software product, while MLOps focuses on delivering a working machine learning model.
    • Version control—DevOps is mainly concerned with tracking binaries and software artifacts, while MLOps tracks additional factors like hyperparameters and model performance.
    • Reusability—DevOps and MLOps both strive to create reusable processes and pipelines, but use different strategies to achieve repeatability. 
    • Continuous monitoring—Monitoring is important to DevOps, but even more important in MLOps because models degrade in performance due to model and data drift.

    Finally, I covered a few key trends that will transform DevOps and MLOps in the near future. I hope this will be useful as you discover your place in the new and exciting development ecosystem.

  • GitHub Brings 2FA to JavaScript Package Manager

    GitHub Brings 2FA to JavaScript Package Manager

    GitHub has made generally available a two-factor authentication tool for the package manager for JavaScript applications maintained by its NPM, Inc. arm.

    In addition, all npm packages have been re-signed and there is now an npm command line interface (CLI) command to audit package integrity.

    Finally, GitHub has added the ability to connect GitHub and Twitter accounts to npm along with a streamlined login and publishing experience with the npm CLI.

    Myles Borins, staff product manager for open source at GitHub, said these enhancements are part of an ongoing effort to enable organizations to better secure their software supply chain by better protecting credentials against being used to take over GitHub accounts.

    There isn’t a huge volume of these types of attacks, but it’s apparent cybercriminals are attempting to compromise the security of software supply chains by gaining illicit access to the platforms used to build applications, noted Borins. Once cybercriminals gain access, they could potentially insert malware in software components that could find its way into any number of downstream applications. That malware can then be used to, for example, potentially launch a ransomware attack or simply exfiltrate data. More troubling still, that malware might begin to spread laterally across an entire application environment.

    GitHub is currently dealing with the fallout from a report that its repositories were attacked; that turned out to be a false alarm. The repositories attacked turned out to be either forks or clones of real, popular repositories with names similar to legitimate repositories on the GitHub platform. No malicious code was actually merged into any of the original repositories; however, it’s apparent cybercriminals are using a technique known as spoofing commit metadata to attempt to trick developers into committing code to a fake repository.

    The challenge that GitHub is trying to navigate is the degree to which some security controls should be enabled by default based on the level of risk, said Borins. Individual developers, for example, might have a higher tolerance for risk than an enterprise IT organization building an application that is core to the processes that drive the business, he noted. In some cases, organizations may opt to restrict access altogether whenever a user name/password can’t be remembered while others will simply limit access to ensure productivity is maintained, added Borins.

    In general, the average enterprise IT organization is likely to have a higher tolerance for disrupting workflows to make sure critical intellectual property is always protected, he added.

    The critical issue, of course, is no one knows for sure what open source component might one day wind up in what application. Regardless of the type of application, developers now routinely reuse code that could contain any number of known vulnerabilities or zero-day vulnerabilities that have yet to be discovered. The foundation for building secure DevSecOps workflows for most organizations at a bare minimum is going to start with implementing two-factor authentication, said Borins.

    Regardless of the DevSecOps approach, just about everyone recognizes there is a need to better secure software supply chains. The one thing that remains to be determined is what impact achieving that goal might actually have on the rate software is being built and delivered.

  • CREST Defines Quality Verification Standard for AppSec Testing

    CREST Defines Quality Verification Standard for AppSec Testing

    At the Black Hat USA 2022 conference, CREST today shared a quality assurance verification standard to improve application security testing. The standard is based on the open source framework defined by the Open Web Application Security Project (OWASP).

    Tom Brennan, executive director for Americas at CREST, said the OWASP Verification Standard (OVS) measures an organization’s ability to execute and deliver assessments related to Level 1 and Level 2 of the OWASP Application Security Verification Standard (ASVS) and OWASP Mobile Application Security Verification Standard (MASVS).

    The goal is to provide a consistent methodology for accrediting companies that provide application security testing services, said Brennan. Ultimately, organizations of all sizes will then be able to require application software providers to pass an OWASP accreditation test rather than testing the security of every application they use, he noted.

    Organizations need to be accredited through CREST Penetration Testing to apply for the OVS program, which requires companies to demonstrate that they can meet the program requirements and execute and deliver Level 1 and Level 2 ASVS and MASVS services. Level 1 determines whether or not applications store or handle sensitive data; that determination then defines whether or not they need the more rigorous controls of Level 2 or 3. Level 1 controls can be checked either automatically using tools or manually without access to source code. Level 2 ensures that security controls are in place, effective and used within the application. In addition, all organizations will need to ensure that their teams have completed CREST’s Skilled Person Register and have each signed the CREST code of conduct.

    CREST is a nonprofit organization that was originally known as the Council of Registered Ethical Security Testers. CREST works with governments, regulators and multinational organizations to improve application security using CREST OVS Mobile and CREST OVS Apps accredited services. It’s becoming more common for organizations to require OVS to better ensure application security in much the same way they require compliance with frameworks such as the System and Organization Controls (SOC) framework, said Brennan.

    OWASP is administered by a separate nonprofit foundation that works to improve the security of software by sponsoring community-led open-source software projects and training application developers. By aligning with OWASP, CREST creates a verification standard to provide a more structured approach to implementing ASVS and MASVS, noted Brennan.

    OVS, of course, is arriving at a time when there is now a much greater focus on software supply chain security in the wake of a series of high-profile breaches. It is apparent cybercriminals have become more adept at discovering and exploiting a wide range of known software vulnerabilities. The Biden administration has even gone so far as to issue an executive order requiring federal agencies to review the security of their software supply chains.

    It may be a while before application testing using OVS becomes routine, but as more organizations embrace DevSecOps best practices to secure their software supply chain it’s clear there is a greater need for application security testing standards. Especially those that organizations can extend versus reinventing the wheel.

  • IBM Unveils Simulation Tool for Attacking SCM Platforms

    IBM Unveils Simulation Tool for Attacking SCM Platforms

    At the Black Hat USA 2022 conference, IBM today revealed it is making available a toolkit for launching simulated attacks against source code management (SCM) platforms. The toolkit was launched as a proof-of-concept.

    Brett Hawkins, head of adversary simulation for the X-Force Red arm of IBM Security, said the SCMKit takes advantage of the REST application programming interface (API) functionality in most SCM platforms to launch various types of attack modules using validated SCM platform credentials. IBM also described a series of attack scenarios that the simulation tool can be used to launch.

    The SCMKit can currently launch simulated attacks against GitHub Enterprise, GitLab Enterprise and Bitbucket Server. The kit can support reconnaissance, privilege escalation and persistence attack module capabilities for creating personal access tokens or secure socket shell (SSH) keys. The SCMKit is based on a modular framework that makes it possible to add additional modules in the future, added Hawkins.

    IBM created the SCMKit to focus more attention on an attack vector that can be exploited to compromise a software supply chain, said Hawkins. In the wake of a series of high-profile security breaches, the Biden administration issued an executive order that required federal agencies to review the security of their software supply chains. While there is more awareness of the issue than ever, Hawkins noted there has not been nearly as much focus on identifying specific attack vectors against SCM platforms that cybercriminals are able to exploit.

    It’s not clear to what degree organizations are launching penetration tests against their preferred SCM platform as they work to secure software supply chains. However, it won’t be long before testing the security integrity of those platforms becomes more commonplace. In some instances, organizations will launch those tests themselves. In other cases, third-party IT services firms will be tasked with launching those tests.

    Of course, the challenge is that penetration testing techniques are also often used by cybercriminals to conduct reconnaissance. The SCMKit doesn’t uncover any new techniques, but it does provide cybercriminals with a guide for launching attacks against SCM platforms. As such, IT organizations should assume these types of attacks will increase in frequency in the months ahead.

    Regardless of the tool employed, it’s clear that cybercriminals have come to appreciate the fact that software supply chains are the soft underbelly of IT. Organizations today have typically focused most of their security efforts on production environments. However, malware inserted into, say, a software repository could easily find its way into multiple downstream applications. At some future date, the malware then reaches out to a command-and-control system that then enables cybercriminals to, for example, launch a ransomware attack or simply exfiltrate data. That malware could also move laterally across an application environment to wreak additional havoc.

    It may be a while before the full extent of the threat to application security is fully appreciated, but as more organizations embrace DevSecOps best practices to secure their software supply chain, it’s all but certain that penetration testing will become much more pervasive in DevOps environments.

  • GitHub Adds Tools to Simplify Management of Software Development

    GitHub Adds Tools to Simplify Management of Software Development

    GitHub has made generally available Projects powered by GitHub Issues, a set of tools for managing application development projects based on a spreadsheet interface.

    Mario Rodriguez, vice president of product management at GitHub, said these tools enable DevOps teams to more easily filter, sort and group issues and pull requests. That capability makes it possible to, for example, configure and track cycle velocity and current work status and create visualizations using cumulative flow diagrams.

    Over the course of the rest of this year, Rodriguez said GitHub also plans to add additional capabilities including custom triggers, conditionals and action logic along with a mobile edition of Projects powered by GitHub Issues.

    The overall goal is to provide DevOps teams with a set of project management tools that enable organizations to plan where they code, said Rodriguez. In many cases, that approach eliminates the need to deploy a separate set of project management applications, he added.

    As more organizations become dependent on software to drive digital business processes, it’s become apparent that managing all the ongoing application development projects has become a significant challenge. GitHub has been developing Projects powered by GitHub Issues to provide organizations with a set of tools that can be accessed not just by DevOps teams but also by application owners and business leaders to track the status of various projects, said Rodriguez.

    Most organizations have not reached the point where revenue growth is completely dependent on the rate at which software is developed and deployed, he noted. However, as DevOps teams more regularly engage other departments in the business, Projects powered by GitHub Issues can provide anyone with access to a spreadsheet-like application that is simple to use, said Rodriguez.

    In general, GitHub is committed to improving developer experiences at a time when organizations are competing for the best talent available, added Rodriguez. If salary and benefits are equal, the decision to work for one company versus another comes down to the quality of the application development experience, he noted.

    As the provider of the most widely-used code repository, GitHub has been extending the reach and capabilities of its platform to address a range of DevOps workflow issues. The issue that DevOps teams need to address is how to anchor those workflows to a code repository versus the continuous integration/continuous delivery (CI/CD) platforms they employ to build and deploy applications.

    Regardless of approach, there’s no doubt that DevOps teams can now construct more scalable workflows. That’s critical, because the number of concurrent application development initiatives that organizations are managing simultaneously has increased substantially in recent years. The underlying platforms used to manage those projects need to be extensible to prevent workflows from becoming overly rigid, said Rodriguez.

    It’s not clear to what degree business leaders appreciate the value of DevOps workflows, but as business processes continue to evolve, the ability to effectively compete could rest on the agility of an application development team.

  • Preparing Your Android App for an Independent Security Review

    Preparing Your Android App for an Independent Security Review

    As of July 20, 2022, Android developers publishing new or updated mobile apps in Google Play must declare how their apps collect, share and secure data. The new Google Play Data safety section provides greater transparency and enables users to examine an Android mobile app’s security and privacy practices to decide which ones to download. Developers can take an extra step to safeguard user trust and demonstrate a high standard of mobile security and privacy by undergoing an optional independent security review. Founded by Google and industry security partners, the App Defense Alliance (ADA) established the mobile application security assessment (MASA) program to validate mobile apps against a globally recognized industry standard.

    Mobile app developers can work with ADA-authorized labs to have their apps assessed against the Open Web Application Security Project (OWASP) mobile application security verification standard (MASVS) L1 requirements to gain the MASA validation. Developers whose mobile apps have passed an independent security review will be able to highlight that distinction in their Google Play Data safety section with the independent security review badge.

    Mobile security experts from an ADA-authorized lab use the MASA specification crafted from the OWASP mobile security testing guide (MSTG) through a mix of automated and manual application security testing to independently assess the Android apps against a set of checks in six key areas.

    To prepare for their independent security review, developers should follow these secure coding best practices when building their Android mobile apps.

    Android Data Storage: Security and Privacy

    ● Use the Android Keystore system to securely store credentials including passwords, private keys, cryptographic keys and other information.
    ● Do not store sensitive data in external storage.
    ● Do not write sensitive data to the system or in application logs.
    ● Do not cache sensitive inputs, such as password fields.
    ● Mask sensitive data during user input.
    ● Fill out the Google Play console data safety section accurately, including both app code and SDKs.

    Encryption

    ● Check first- and third-party code to confirm the use of industry-standard cryptographic libraries and algorithms (with recommended settings).
    ● Avoid outdated cryptography algorithms (such as MD5 or SHA-1) for sensitive data or authentication routines.
    ● Do not hardcode cryptographic keys or initialization vectors (IVs).
    ● For security, use pseudorandom number generators (PRNG) compliant with FIPS 140-2 security requirements for cryptographic modules.

    Authentication and Session Management

    ● Ensure API endpoints that provide access to sensitive data require authentication.
    ● Use randomly generated session identifiers.
    ● Ensure sessions terminate at a remote endpoint when users log out.
    ● Include password complexity requirements enforced on both the client and server sides.
    ● Enable brute force protection for authentication endpoints.
    ● Ensure tokens have a reasonable expiration/timeout.

    Android Network Communications

    ● Transmit all app data over TLS.
    ● Ensure the app verifies the validity of the certificate during the exchange.
    ● Declare all transmitted data.

    Platform

    ● Do not request unnecessary app permissions.
    ● Validate any input your app accepts from external sources and sanitize if necessary.
    ● Ensure sensitive functionality is protected against unintended access for security and privacy.

    Code Quality

    ● Remove all debugging symbols from the app and libraries.
    ● Remove debugging code (such as hidden settings).
    ● Disable verbose logging.
    ● Account for third-party SDKs in the data safety section.
    ● Update third-party SDKs and remove critical vulnerabilities.
    ● Enable PIC and stack smashing protection in apps and libraries.

    Obtaining a MASA validation from an ADA-authorized lab gives developers a competitive advantage to drive more downloads by showcasing their commitment to mobile app security and privacy. When given a choice, mobile app users are more likely to download and use Android apps with the independent security review badge in Google Play. And enterprises with higher risk control requirements like finance, health care, energy and government are more likely to purchase and use these verified apps.

  • Armory Extends Scope of Spinnaker CD Distribution

    Armory Extends Scope of Spinnaker CD Distribution

    Armory today updated both the self-hosted and managed editions of its distribution of the open source Spinnaker continuous delivery (CD) platform. The updates support concurrent pipelines and provide tighter integration with open source Terraform infrastructure-as-code (IaC) to better enforce policies.

    Previously, the two platforms were known as Armory Enterprise and Armory Enterprise Managed. They are now being rechristened; Armory Continuous Deployment Self-Hosted becomes Armory Continuous Deployment Managed in part to provide more differentiation from a CD cloud service the company rolled out last month that is not based on Spinnaker.

    Adam Frank, vice president of product for Armory, said other capabilities added to the platform include additional testing tools for contributions to the Spinnaker platform as well as enhanced plug-ins and remediation capabilities for Common Vulnerabilities and Exposures (CVEs) that might impact the Spinnaker platform.

    Despite launching a declarative CD-as-a-service platform that is not based on Spinnaker, Armory remains committed to supporting organizations that prefer to continue to rely on the open source platform, said Frank.

    The number of organizations that routinely make use of a dedicated CD platform is still relatively small. While organizations have been employing continuous integration (CI) within a CI/CD platform, making use of the CD element of those platforms has proven challenging. Each platform used to run applications has been unique, so automating delivery has been problematic. CI platforms, in some cases, have been extended using custom scripts to automate application delivery, but those efforts don’t typically scale across an extended enterprise. Many organizations that attempted to extend the open source Jenkins CI/CD platform, for example, are now looking to more loosely couple CI and CD processes to make DevOps workflows less brittle, noted Frank.

    Armory is making a case for a distinct CD platform at a time when more organizations are starting to build microservices-based applications on Kubernetes clusters that expose a standard set of application programming interfaces (APIs) regardless of what infrastructure they are deployed on. In many cases, those organizations now need to manage multiple pipelines in parallel as application environments become more complex rather than relying on a single pipeline, noted Frank.

    There’s no doubt that as the pace of application development continues to accelerate, the need to automate CD will become a more pressing issue. DevOps teams are releasing a larger number of smaller updates to applications and there’s also a need to be able to easily roll back those updates in case an unexpected issue is encountered, said Frank.

    It’s not clear yet how many organizations will be adopting dedicated CD platforms, but as application development continues to evolve many DevOps teams will, at the very least, be revisiting their existing processes. At the same time, there are also many organizations that are just beginning their DevOps journey. Most of those organizations are not committed to one CI/CD approach versus another.

    Regardless of approach, however, the expectation in the era of digital business transformation is organizations will be able to deliver software updates in a timely manner. The only way to achieve that goal, however, will be to have some type of CD capability that reliably operates at the scale required by organizations that need to operate like a true software company.

  • Palo Alto Networks Extends Checkov Tool for Securing Infrastructure

    Palo Alto Networks Extends Checkov Tool for Securing Infrastructure

    Palo Alto Networks has added support for GitHub Actions, GitLab Runners, CircleCI and Argo Workflows to Checkov, an open source tool that scans programmatically provisioned infrastructure for misconfigurations.

    Guy Eisenkot, senior director of product at Bridgecrew by Prisma Cloud at Palo Alto Networks, said the goal is to make it easier to secure configurations created using infrastructure-as-code (IaC) tools such as Terraform.

    Those additions are now available as part of a Checkov library of policies, including graph-based checks, that provide a context-aware way of identifying risks within infrastructure and application code within a DevSecOps workflow using a tool that enables IT teams to manage policy-as-code, he noted.

    Misconfigurations of cloud infrastructure have become a major issue. Typically, that infrastructure is programmatically provisioned by developers that have little to no cybersecurity expertise. As a result, cybercriminals are now more aggressively scanning for misconfigurations that they can exploit to, for example, exfiltrate data or illicitly access services via application programming interfaces (APIs). Checkov makes it easier to identify those potential security issues within the context of a DevOps workflow before cloud infrastructure is provisioned, noted Eisenkot.

    There is a lot more focus on securing software supply chains in the wake of a series of high-profile breaches. The Biden administration last year even went so far as to issue an executive order requiring federal agencies to review the security of their software supply chains. The challenge is that most organizations have yet to implement a truly developer-centric approach to ensuring application security, said Eisenkot.

    In general, cloud platforms are more secure than on-premises IT environments; however, the processes used to build and deploy cloud applications today are clearly problematic. A chronic shortage of cybersecurity staff further aggravates the issue, because most organizations are not able to keep pace with the rate at which workloads are being deployed in the cloud.

    As more organizations are also starting to embrace DevSecOps best practices, the overall state of cybersecurity should improve. The challenge is that no matter how much time and effort is made to educate developers, there will always be mistakes a cybercriminal can exploit. Policy-as-code tools like Chekhov make it much less likely those mistakes will carry over into a production environment.

    In the meantime, organizations need to work on work on bridging the long-standing divide between application development and cybersecurity teams. Historically, cybersecurity teams would aggregate vulnerabilities they discovered in spreadsheets that developers would then be asked to remediate. The issue is not only the lack of time to address those vulnerabilities but also the lack of context provided. Many of those vulnerabilities often turn out to not be applicable to the way an application is deployed. Over time, application developers start to ignore many of those requests in favor of focusing their efforts on writing additional code. Of course, the more code that is written the greater the number of vulnerabilities that need to theoretically be remediated until a vicious cycle is created.

    Of course, it’s only a matter of time before one vulnerability winds up being a critical exploit and becomes the exception to that rule.