devopsy.kinsta.cloud

Tag: mobile apps

  • Copado Streamlines Custom Salesforce App Testing

    Copado Streamlines Custom Salesforce App Testing

    Copado today added a testing tool to its platform for managing DevOps workflows in Salesforce application environments that automatically creates scripts based on manual tests being conducted.

    Announced at the TrailblazerDX conference hosted by Salesforce, Copado Explorer enables DevOps teams to integrate those scripts into testing processes that can be repeated as required.

    David Brooks, senior vice president and lead evangelist for Copado, said the goal is to make it simpler for DevOps teams to add those tests to the regression tests that are incorporated into pipelines created using the Copado continuous integration/continuous delivery (CI/CD) platform.

    In addition, markup and annotation tools enhance collaboration by allowing non-technical subject matter experts to provide detailed feedback and insights to quality assurance and development teams as part of an effort to streamline communications between product owners, testers and developers. Testers without a technical background can use that capability to contribute to the creation and deployment of effective automated tests. That capability makes it possible to shift testing further left to incorporate the business teams that better understand how an application should function, said Brooks.

    The challenge is far too many organizations still overlook the importance of testing, noted Brooks. There is a tendency when using low-code tools to assume that not as much testing is required because the tools that generate code create a false sense of instant quality despite flaws that might not manifest themselves until an application is deployed, noted Brooks.

    Rather than constantly updating applications, more testing should improve the quality of the applications being built sooner. That’s critical because most organizations don’t have the time and resources needed to continuously iterate applications until they eventually arrive at what the business requires, said Brooks.

    It’s still early days so far as the level of DevOps maturity that organizations using the Salesforce platform to build and deploy custom applications have thus far attained, noted Brooks. However, just about every organization that licenses the software-as-a-service (SaaS) platform from Salesforce customizes those applications to better align them with their internal business processes, he added.

    Each organization will naturally need to determine to what degree they are prepared to deploy customer applications, but it’s clear it’s becoming simpler to build them. Late last year, Copado, for example, added generative artificial intelligence (AI) tools to make it easier to manage the DevOps workflows used to build these applications, which means the speed at which these apps are built and deployed is about to exponentially increase.

    Salesforce, of course, is only one of many SaaS platforms that organizations rely on to build and deploy custom applications. However, as one of the most dominant platforms, the pace at which custom applications are being built continues to increase, with a larger percentage of these applications being built by professional developers familiar with DevOps best practices.

    Eventually, those DevOps workflows will be extended to every kind of developer, but for now, most organizations building applications are looking for more consistent outcomes regardless of what type of tool is used to build them.

  • Improving the DevOps Process for Mobile App Developers

    Improving the DevOps Process for Mobile App Developers

    Development teams—perhaps especially mobile development teams—have heavily invested in systems to automate their processes and accelerate the delivery of mobile apps. From build, test and release to tracking and monitoring, the mobile DevOps team depends on systems like Fastlane, Bitrise, Jenkins, Azure Pipelines and GitLab—and really, that list just scratches the surface.

    The mobile app market moves so fast that automation is the only way mobile DevOps teams can keep up with their competitors and rapidly changing customer expectations. They have to iterate and release rapidly—the more frequently a publisher puts out new features, the more highly customers rate their app. In the GitLab 2022 Global DevSecOps Survey, 70% of respondents said their teams release code every day or every few days.

    Unfortunately, there’s one major component of mobile app development that sits outside of these automated processes in most mobile DevOps teams: Security. For the most part, developers still implement security manually, and the process for ensuring apps are secure mostly comes down to code scanning and penetration tests. Again, from the GitLab survey, 53% of developers are running static application security testing (SAST), but unfortunately, the data from those scans is often not feeding back into developer workflows. Less than three out of 10 teams (29%) pull scan results into a report for developers.

    Additionally, there’s still a large disconnect between the security and development teams. Nearly half (47%) of security pros said that developers miss more than three-quarters of the bugs in the code, leaving them for the security teams to find, and more than half (56%) said it was hard to get developers to prioritize fixing code vulnerabilities. In fact, prioritizing vulnerability remediation was security professionals’ biggest challenge. Additionally, it’s interesting that when it comes to shift left security, the emphasis appears to be on early code scanning, not actually building security into apps earlier in the process.

    Data-Driven Decisions and Security Automation

    First, DevOps teams need to integrate data about the security of their mobile apps early in the process so they can make informed decisions about what protections to incorporate into the next build. Scanning information and results from penetration tests clearly need to feed back to the development team as quickly as possible—there’s no point in doing these tests if the information remains unavailable and not acted on.

    But mobile devices have the capability to collect and send much richer data about the security threats apps are actually facing in the field. By collecting this data, DevOps teams can make data-driven decisions about which threats are the highest priority to combat.

    However, as noted earlier, it does little good to collect data if it’s never used. And the slow pace of manual security implementation does not allow DevOps teams to implement protections quickly or nimbly enough to keep pace with the rapidly changing threat environment. DevOps teams need to automate the build, testing, release, tracking and monitoring of security to the same degree as every other aspect of an app’s development. Specifically, they need:

    • A system that can store, provide version control and audit security in every release
    • An automated system that can build the desired protections into the app within the organization’s existing CI/CD processes
    • Automated verification that the protections slated for implementation are actually included in the release
    • A feedback system from data collected in the field, including data about the effectiveness of protections already implemented. This proves security measures are working and reinforces the value of the DevSecOps process.

    With this combination of data and automation, mobile app developers can transition from DevOps attempting to shift left security towards a DevSecOps process that is completely data-driven. Instead of reacting to the latest threat that’s making headlines in the news or working off gut feelings about the direction the threat environment is moving, DevOps teams can look at trending threat data from their very own apps, slicing it according to growth, geography, device, OS version and a multitude of other filters. As a result, the organization can pinpoint exactly which threats are emerging as the next big thing so they can defend against them early.

    And with the assistance of automation, the DevOps team can keep up with the trending data, building security protections into the app within days or even hours of making a decision on what to include.

    To improve the DevOps process, security has to shift left, but moving code scanning and penetration testing earlier in the process won’t do much good to harden protection without real-time data from the field and automation for security implementation. What DevOps needs is a transition to data-driven DevSecOps.

  • Tricentis Extends Mobile Testing Reach

    Tricentis Extends Mobile Testing Reach

    Tricentis has added the ability to test native iOS and Android applications to its Testim software-as-a-service (SaaS) platform.

    Previously, the Testim platform was designed to test web applications, but is now being extended as organizations build and deploy more native mobile applications. Capabilities of the Testim Mobile platform include codeless authoring of mobile tests to eliminate the need to write and maintain Appium, Espresso or XCUITest scripts and the ability to set up, configure and manage mobile devices in minutes using the Tricentis Mobile Agent.

    Additionally, applications can be uploaded to the cloud to enable collaboration across testing teams as they opt to run tests on real or virtual devices. DevOps team can also customize tests with JavaScript, branch tests, and run tests from a scheduler or continuous integration (CI) build.

    Tricentis CTO Mav Turner said Tricentis is moving to implement a consistent set of mobile testing services across its entire portfolio of testing platforms now that mobile applications are equal, first-class citizens alongside web applications. The primary driver of that shift has been the COVID-19 pandemic, which saw more organizations relying on external-facing mobile applications to engage customers, partners and employees working remotely, he added.

    Testing those applications is more critical than ever because the cost of failure—in terms of impact to the business—is now much higher as more organizations depend on software to drive business processes, noted Turner.

    The goal is to make it simpler to test these applications as they are being developed to ensure quality, he added. The challenge is that many developers don’t have a software engineering mindset. Hence, they need to rely more on testing platforms infused with artificial intelligence to discover issues relating to, for example, scalability and security, said Turner.

    Most organizations are trying to shift more responsibility for testing toward developers as part of an effort to remediate issues earlier in the software development life cycle. It’s more challenging for developers to remediate issues after an application has been developed simply because they have lost context. Testing platforms infused with AI capabilities make it easier for developers to identify issues at the time they are writing code. In the future, Tricentis expects to take advantage of generative AI platforms to make it easier to author tests using a set of best practices that can be easily reused, noted Turner.

    That approach doesn’t necessarily eliminate the need for a dedicated quality assessment review, but it does allow testing teams to focus more of their time and effort on testing the application experience versus identifying lower-level errors that many developers routinely make.

    Over time, the quality of applications should steadily improve as many of the low-level mistakes that developers make are eliminated. That should improve everything from application security to the user experience as applications are continuously updated. In the meantime, organizations that embed testing within DevOps workflows are steadily reducing the number of issues that need to be addressed just before applications are supposed to be deployed.

  • Architecting an Auth System for Applications

    Architecting an Auth System for Applications

    Applications today use many login and authentication methods and workflows. Here, I’ll share the most relevant and proven authentication workflows, which you can use as a basis for architecting and designing an authentication system for traditional web applications, single-page applications and native mobile applications.

    Authentication Workflows for Traditional Web Applications

    Traditional web applications load a web page and provide user functionality using a message-based model where a browser makes an HTTP request to a web server based on the URL in the address bar. The server responds to this request with HTML, CSS and JavaScript and then displays a resource in the browser. Along with traditional web apps, new web apps often still provide functionality in this manner.

    When a user submits a form or clicks a link or button, the browser sends a new HTTP request to the web server and changes the URL in the address bar. The server again responds by returning HTML, CSS and JavaScript and then displaying a resource in the browser.

    Browsers support only two HTTP methods for traditional web apps: GET and POST. GET is used to request data from a specified resource and POST is used to send data to a server to create or update a resource.

    Below are several workflows you can use for traditional web app login and authentication. Note that the application backend is the backend of the application (not the identity provider, or IdP) and native login form is a form built directly into the application instead of an external login form.

    Native login form to the application backend using …

    JWTs and refresh tokens stored in cookies

    Sessions

    Sessions plus refresh tokens stored in cookies

    OAuth 2 authorization code grant using …

    JWTs and refresh tokens stored in cookies (RECOMMENDED)

    Sessions (RECOMMENDED)

    Sessions plus refresh tokens stored in cookies

    OAuth 2 resource owner password credentials grant using …

    JWTs and refresh tokens stored in cookies

    Sessions

    Sessions plus refresh tokens stored in cookies

    Authentication Workflows for Single-Page Applications

    A single-page web app (SPA, pronounced as “spa” or “S-P-A”) runs entirely in the browser after loading the HTML, CSS and JavaScript source code from a web page. After retrieving the HTML, CSS and JavaScript that make up the application, the browser invokes a JavaScript framework that bootstraps and then renders the application.

    SPAs call APIs to handle user interactions and input. For example, if a user clicks a link or submits a form, the SPA might render a different page or form.

    APIs are invoked using XMLHttpRequest, a built-in browser object that can make HTTP requests in JavaScript. When the server responds, the JavaScript running in the browser updates the data dynamically without performing a  full page refresh.

    SPAs use a single request and response model. Since the browser uses XMLHttpRequest, it can support GET and POST, as well as other standard HTTP methods, such as PUT and DELETE. (PUT is used to replace all current representations of the specified resource and DELETE is used to, well, delete the specified resource.) The HTTP method chosen tells the server how to handle the request.

    Here are some workflows you can use for SPA login and authentication.

    Native login form to the application backend using …

    JWTs and refresh tokens stored in cookies

    Sessions

    Sessions plus refresh tokens stored in cookies

    Native login form to FusionAuth using …

    JWTs stored in local storage and refresh tokens stored in cookies

    JWTs and refresh tokens stored in cookies

    JWTs and refresh tokens stored in cookies

    OAuth 2 authorization code grant using …

    JWTs and refresh tokens stored in cookies (RECOMMENDED)

    Sessions (RECOMMENDED)

    Sessions plus refresh tokens stored in cookies

    OAuth 2 implicit grant using …

    JWTs stored in cookies

    JWTs stored in local storage

    Sessions

    OAuth 2 resource owner password credentials grant using …

    JWTs and refresh tokens stored in cookies

    Sessions

    Sessions plus refresh tokens stored in cookies

    When using OAuth for SPAs, note that the browser navigates away from the SPA to the OAuth provider. Once the OAuth workflow is complete, the browser is sent back to the SPA page where it quickly restarts the SPA with cached assets.

    Authentication Workflows for Native Mobile Applications

    Native mobile applications are usually installed on a mobile device or any smart device through an online marketplace like App Store and Google Play Store. Clicking the application icon on the device launches the device operating system, which starts the application and its user interface.

    Almost all native applications call APIs on the server to handle user interactions and input, such as button clicks and form submissions. Native applications often use libraries designed to directly access all of the classes, objects, functions and methods of the source code to communicate quickly with APIs and simplify API calls.

    auth mobile

    Here are a few workflows you can use for native mobile application login and authentication:

    Native login form to the application backend using JWTs and refresh tokens

    Native login form to FusionAuth using JWTs and refresh tokens (RECOMMENDED)

    OAuth 2 resource owner password credentials grant using JWTs and refresh tokens

    Note that native mobile applications can also use the OAuth authorization code grant to exchange an authorization code for an access token. This workflow works with many IdPs and is essentially the same as described in the preceding traditional web application and single-page application sections. The main difference is that the native application pulls the JWT and refresh tokens from the web view at the end of the OAuth workflow.

    Authentication System Best Practices

    The workflows listed above should give you a baseline for following authentication system best practices and architecting a sound login and authentication system for your applications. While these examples use FusionAuth as the IdP, any IdP can be used. Most IdPs are capable of a wide variety of login and authentication workflows, and the examples here are not meant to be exhaustive.

    As you’re designing an authentication system for traditional web applications, single-page applications or native mobile applications, keep in mind that some IdP login workflows can pose serious security risks. As with all things having to do with digital identities and user and data security, it’s important to choose both your IdP and your authentication workflow wisely.

  • GitLab Makes Building Secure Mobile Apps Easier

    GitLab Makes Building Secure Mobile Apps Easier

    GitLab has made 60 enhancements to its namesake continuous integration/continuous delivery (CI/CD) platform to address a range of things from DevSecOps processes to collaboration, at a time when most DevOps teams continue to work remotely.

    With help from external contributor support for the Mobile Security Framework (MobSF), version 13.5 of GitLab adds an all-in-one tool for penetration-testing, malware analysis and security assessment that runs both static and dynamic analysis of code running on Android, Apple iOS or Windows platforms. GitLab is also making available a user interface to configure its existing static analysis security tools.

    On the collaboration front, GitLab has added support for Group Wikis to provide a central place to collaborate as well as an enhanced Snippets tool to facilitate code-sharing among group members. Snippets with multiple files are now supported inside a single Snippet.

    GitLab is also making available additional templates for deploying to Amazon Web Services (AWS), as well as a GitLab CI/CD template for Terraform and integration with Gitpod, a tool that makes it easier to spin up development environments.

    Finally, GitLab has made feature flags a core part of its platform and added support for a Timeline view to make it easier to navigate incident discussions. It also included the ability to store other binary types in GitLab that are not yet supported via raw package feeds and attach binary assets to releases.

    Brendan O’Leary, senior developer evangelist for GitLab, the COVID-19 pandemic has accelerated digital business transformation initiatives that often depend heavily on secure mobile computing applications that rely on rapid development. As the DevOps teams tasked with building these applications are working from home to help limit any spread of the pandemic, the need for tools to facilitate collaboration across distributed development teams has become critical, he said.

    It’s not clear to what degree the need to work from home is influencing the selection of CI/CD platforms just yet. The trend toward working remotely was well underway prior to the pandemic. At this juncture, however, it’s clear most development teams will be working remotely well through 2021. Most IT organizations will need to revisit some early assumptions about how to optimize DevOps practices across a distributed workforce now that many of them have had firsthand experience, noted O’Leary.

    The challenge is some developers may thrive while working from home while others struggle. In the absence of collaboration tools, it becomes more challenging for managers to ascertain what specific issues need to be addressed. Of course, even if a vaccine is discovered. there will be no going back—the way applications are built and deployed in a modern enterprise has been forever altered. The issue now is determining how best to move forward as the COVID-19 pandemic continues waxes and wanes.

  • 4 Mobile DevOps Must-Haves

    4 Mobile DevOps Must-Haves

    Mobile DevOps requires a robust and streamlined strategy for success

    The mobile revolution of the last 20 years has radically changed our everyday lives. That’s not just the way we communicate, but also the way we find information, purchase goods and services, entertain ourselves and more. This has gone in tandem with great technological advances elsewhere, including small-business VoIP. Now it’s never been easier to organize a business teleconference or simply catch up with friends and family, wherever they happen to be.

    Recent years have seen mobile apps scale new heights of technological achievement. This plethora of new apps has changed the way we work, play and chat. But that’s not all. It’s also changed people’s expectations—and it’s up to businesses to respond to that. Consumers expect apps tailored to suit the different aspects of their lives. This puts a great deal of pressure on businesses and other organizations to meet these higher and more demanding expectations.

    That’s why so many are taking advantage of the opportunities offered by mobile DevOps. In a nutshell, the purpose of DevOps is to facilitate enhanced collaboration between project managers, mobile developers and ordinary employees. This helps businesses to meet their goals more effectively, while also ensuring that users enjoy the best and most convenient experience possible. It also means that businesses don’t have to go through the hassle of using native apps to create new hybrid products, greatly simplifying their tasks.

    But without a robust and streamlined strategy in place, mobile DevOps won’t automatically deliver the goods. You need to have a solid understanding of a range of different factors. These will include user preferences, development trends and software delivery. One thing that is clear is that consumer expectations are changing at a remarkable rate and you need to ensure that your offering is up to par. Agility is the watchword, and your DevOps strategy needs to have this flexibility built-in.

    Elements for Successful Mobile DevOps

    Here we’ll take a look at four must-haves of any streamlined mobile DevOps strategy to help you get started. Read on to find out more.

    Planning

    It might seem like an obvious point to make, but thorough planning is the indispensable foundation of any effective mobile DevOps strategy. Having said that, you’d be surprised just how many firms fail to take this basic requirement properly into account. It doesn’t matter exactly what your specialism is—whether it’s HR software or telemedicine app development—your project must be planned in fine detail.

    Get everyone who’s working on the project together. That means all stakeholders, from your developers and testers to your operations team and others. It’s then that you can start to map out what form your project will take. It’s a good idea to get clients involved at this early stage as well, because it’s imperative to keep their needs in mind at all times. Think about what everyone requires from the project (including quality control requirements) and how to deliver it. Consider the potential risks involved and what steps you might take to mitigate these.

    People and Communication

    It’s the same with any project—unless you’ve got the right people on board and the right chemistry between them, you’re almost certainly doomed to fail. Your team, therefore, is of the utmost importance. Mobile DevOps inevitably involves a wide array of different people with unique skill sets, who will make their own particular contributions to the project. You should prioritize finding the right mix and maintaining morale across the board. This will go a long way to ensuring harmonious working between the different wings of your team.

    Part of keeping team morale high is making sure that communications between different parts of the team are smooth. DevOps projects, as we’ve noted, tend to have quite a large number of people working on them. There is a danger that different teams can become somewhat siloed. That’s where each smaller element of the team fails to work coherently with those around it. You should, therefore, make a concerted effort to keep the different groups working on your project collaborating closely with one another. In this way, your people are sure to add up to more than the mere sum of their parts.

    Testing, Monitoring and Delivery

    Continual testing, monitoring and delivery are all essential to ensure that deployment is smooth and free of avoidable errors. Every build should be subject to rigorous testing so that any snags can be discovered and ironed out. Monitoring must be similarly thorough at each step of the way. This helps to keep the production process stable so that any unexpected hitches can be dealt with more effectively when they arise. Continual testing and updating are more important than ever, given the advent of the internet of things and its always-on nature.

    It’s also important to remember that speed is of the essence when it comes to mobile DevOps. The more effective your testing, monitoring and delivery processes are, the quicker you’ll be able to roll out new apps—in other words, increasing software velocity—and you’ll be able to do so with confidence that they’ll be reliable, user-friendly and secure. This will help to improve the overall efficiency of the development process, as well as boosting user and client satisfaction. It will also improve return on investment while helping to minimize the risk of cost overruns.

    Quality and Efficiency

    Striking the right balance between quality and efficiency in mobile DevOps may be top of mind for you. We’ve already alluded to the importance of efficiency in DevOps processes. Maximizing quality in the development of new apps can also do a lot to improve efficiency, save money and cut out unnecessary expenses.

    After all, there’s no getting away from it: development can be an expensive business. A laser-like focus on quality can prevent avoidable complications in the development process. Crucially, it also helps to maintain user satisfaction (always a vital consideration). Think about telemedicine app development, for example—a particularly fraught area. A telemedicine app that’s unreliable, prone to errors or generally shoddy could have a devastating impact on a company’s reputation. Robust DevOps tooling not only allows for better quality but also enhances efficiency by freeing up developers and testers to work on other tasks.

  • COVID-19, the New Normal and the Indisputable Importance of Mobile App Security

    COVID-19, the New Normal and the Indisputable Importance of Mobile App Security

    As the United States emerges from COVID-19 lockdown, it’s not back to business as usual. COVID-19 remains a very serious risk, and until a vaccine or treatment arrives, we will all need to remain vigilant. Further, it’s also certain that the new normal post-COVID-19 world represents a fundamental transformation in how businesses operate, with mobile business models taking center stage.

    For most businesses, their storefront was their most important asset for awareness and revenue generation prior to the pandemic. Having a good physical location was critical to bringing in foot traffic and allowing customers to easily discover them. In the new normal, however, digital location has become far more important as consumers are increasingly turning to their mobile devices. So, it’s critical for businesses to make apps that are easy to find and use in order to continue generating revenue going forward.

    The combination of the pandemic and growing mobile usage has made developing and updating apps not just a nice-to-have marketing tool, but a necessary task for business survival. An enormous number of previously casual mobile users are now depending on mobile apps for their banking, shopping and other day-to-day transactions. As such, businesses need to redesign their apps to ensure they’re easy and intuitive to use so they don’t lose those potential customers. This requires developers to iterate even faster to deliver an engaging, glitch-free experience.

    Unfortunately, in the mad rush to ship apps as fast as possible, security often gets short shrift in favor of features and functionality. According to the Verizon Mobile Security Index 2020, even before the pandemic hit, 43% of app developers said they knew they were cutting corners on security to “get the job done.” 

    Features Trump Security … Until They Don’t

    Now with business models hinging on mobile, developers can no longer rest on “features first, security later” mentalities. The struggle here is that implementing mobile app security is hard to do. It takes time, often extending the development cycle, and it’s expensive. Even if development teams are committed to implementing security, they may lack the skills to do so — good iOS and Android security engineers are scarce and in high demand.

    Eventually, however, poor security will bring consequences. Cybercriminals operate much like nimble startups, searching for opportunities, creating minimal viable malware and then continually improving it to become more effective. Case in point: the EventBot malware for Android that was discovered in April. It masquerades as a legitimate app, such as a banking app or other popular consumer that, once installed, harvest unprotected data from other apps on a device. EventBot also can intercept text messages (SMS) sent to the device, which enables it to capture the identity verification codes used by multi-factor authentication solutions. With access to these codes and the unprotected user credentials found in the app, hackers can easily launch account takeover attacks on tens of thousands of unsuspecting mobile app users.

    What’s more, the new normal post-COVID-19 world is causing a huge increase in app usage, cybercriminals and hackers believe that the time is ripe to start exploiting known mobile app security flaws. For example, it’s not a secret that most mobile apps lack basic encryption. Similarly, most apps can be tampered with, repackaged and distributed on non-official app stores. With malware like EventBot that can be embedded in popular apps that users already trust, the game for mobile app exploits has been upped dramatically.

    EventBot is just one example of why it’s critical for app developers to encrypt all app data (including the strings, resources and in-app preferences that are stored on the device), obfuscate code and shield apps from tampering and reverse engineering efforts. Doing so will stop EventBot and other potential attacks, and prevent cybercriminals from using apps as Trojans for additional attacks.

    Solutions to the Security Development Challenge 

    If a development team decides the best route is to implement security themselves, they should first make sure they have the appropriate skills in house. If so, a good start is to address each of the OWASP Mobile Top Ten vulnerabilities. 

    Other development teams turn to security software development kits (SDKs), which they will integrate into their apps to provide security. This reduces the scope of the coding but still requires developers to have extensive security experience, and it’s critical to vet SDKs before integrating them, because rogue and vulnerable SDKs are a serious problem in the mobile app industry.

    A final option is security automation through artificial intelligence. It’s fast, taking just minutes to completely secure an app without any coding, and compared to manual coding, it’s inexpensive. But, as you should do anytime you’re outsourcing security, do your due diligence to make sure the platform truly secures the app without introducing additional vulnerabilities.

    The new normal has elevated the importance of mobile apps as the primary way customers interact with businesses, and cybercriminals are taking note. So, in the race to provide an engaging, intuitive experience for customers, don’t neglect their safety. Focusing on features and functionality at the expense of security might pay off in the short-term, but the long-term consequences could be grave. Identify the security development model that will work best for your team, but make sure you implement security quickly. Cybercriminals will not wait for you to prepare before launching new, even more devastating attacks.