devopsy.kinsta.cloud

Tag: mobile application testing

  • Implementing Data-Driven DevSecOps

    Implementing Data-Driven DevSecOps

    Right now, the way DevSecOps is typically implemented doesn’t fit with the rapid and agile DevOps CI/CD pipeline at all. It’s like applying 19th-century firefighting methods to a modern forest fire.

    Back then, firefighters employed a “bucket brigade,” where they would form a queue and pass buckets from one hand to another to put out a blaze. No doubt, it’s a lot of work, but much of the effort is wasted. Water inevitably spills out of the buckets as they are handed from one person to the next and by the time the bucket is emptied into the fire, half the water is gone. And not only is so much effort wasted, it’s far too slow and ineffectual to combat the kind of wildfires we face today.

    Likewise, the largely manual methods of current DevSecOps initiatives are ineffectual in fighting the fires of digital threats and cyberattacks modern mobile apps face. Like a modern megafire, these threats and attacks are growing and changing every second, seeking new vectors to spark new attacks elsewhere. Traditional DevSecOps tools like code scanning and penetration testing identify vulnerabilities and then the security teams start the manual “bucket brigade” to add as much protection as they can against them before the app has to be released. But neither the threats nor the CI/CD process has paused. New features have been added that have created new vulnerabilities, and the threat landscape has evolved. It’s inefficient because pentesting can’t provide the kind of real-time data about attacks and threats that developers need to provide protection against current threats. The result is the release of vulnerable mobile apps. 

    A Data-Driven Process

    In business, the C-suite is working hard to transform their companies into data-driven organizations where decisions are made not on the basis of gut feelings or expert opinion, but rather on analysis of hard data. That same approach needs to be brought to security implementation for mobile applications.

    Additionally, the implementation of security into a mobile app needs to be automated. With so much of the CI/CD process already automated, security cannot lag behind.

    These two elements combined create data-driven DevSecOps. In this method, the development and security teams have a system of record that provides real-time cyberattack and cyberthreat information about apps in the field, which drives decisions the team makes about the protections that are most urgent and that must be included in the next build. 

    It’s now well within the realm of possibility for mobile app developers to gather near-real-time information on exactly the kinds of threats and vulnerabilities that their mobile apps are facing in the field. When combined with location, network and other kinds of data, developers can gain a granular understanding not only of the most common threats their apps experience, but also which threats are most prevalent in specific geographic regions. They can also proactively identify the rapidly mounting threats that will become an enormous problem in the near future.

    With this data in hand, development teams can make informed decisions about which protections they should prioritize in the next build to make the best use of their time and resources to provide maximum protection to their end users. 

    The Need for Automation

    But having data isn’t enough. Development teams need the ability to act quickly on the insights provided, and manual implementation methods are too slow and cumbersome to keep up with the rapidly changing threat landscape for mobile apps. Once the decision is made, a system must also exist to automate the incorporation of mobile app security, anti-fraud and anti-cheat protections from within the CI/CD pipeline, so that security implementation runs as smoothly as feature creation.

    The advantages of data-driven DevSecOps are many. First, publishers, developers and security teams can understand exactly what cybercriminals are doing against their own apps with real users. With this data and the wealth of other data that organizations can collect from their apps, they can determine which threats are the most pressing, which are rapidly emerging and even how they are distributed among different geographic regions—all of which is extremely valuable information when deciding which protections to build into the next release.

    Finally, once the app is released, teams can use the data they receive about threats and attacks to prove the effectiveness and value of each protection that was included. It’s important information not only for continuous improvement, but also to justify the value of data-driven DevSecOps to management and the C-suite.

    With data-driven DevSecOps, organizations can provide data, transparency and visibility around security to all stakeholders in the CI/CD process—all while making the incorporation of security far more efficient and effective, along with the real-time data to prove it.

  • Remote Deposit Capture: Mobile Testing for Your Convenience

    Remote Deposit Capture: Mobile Testing for Your Convenience

    “How much of human life is lost in waiting!” penned Ralph Waldo Emerson.

    Any chore that can be digitized is surely welcome. How about cashing a check?

    Cashing a check takes time. You have to go to the bank, wait on line for the next available teller or ATM. If you go to an ATM at night, you have to worry about who is lurking in the shadows outside.

    Is this really necessary?

    More than 7,000 banks have resolved the issue, saving us all time and hassle. You can now take a check, put it on a table, click a picture with your smartphone, and it will appear in your account as a deposit.

    Using remote deposit capture, mobile applications now save you a trip to the bank. But accomplishing this feat was no easy task.

    Mobile Testing for Mobile Banking is Serious Business

    We are dealing with your hard-earned money. All it takes is one small error, and someone has to spend three hours arguing with a bank manager why their savings is a third of what it was last week.

    Then they go on social media to tell their friends how Bank A took all their money. Then the clients of Bank A decide they would be better off moving their money to Bank B. For the banking industry, mobile testing can mean the difference between offering customers a quality-of-life upgrade and losing business.

    For both the customers and the financial institutions the mobile testing process has to be perfect. To do that, we must hurdle three significant challenges:

    Challenge #1: Achieve mobile test automation

    The test coverage for a bank is a lot larger than for most applications. It can’t be achieved without an automated process coming from a cloud-based mobile lab consisting of hundreds of devices with their own versions, and mobile operating systems running tests all at the same time.

    The challenge is that testing for an item external to the device—the check itself—eliminates the chance for automation. How do we install a robot to place a check on a table, pull out a mobile device from where it sits in the lab, and place it just the right distance from the check before taking a picture?

    The solution was to create a repository of more than 100 of the most commonly used checks. Each check has its own size, color and format. A tester selects a particular check from the repository, and uploads the image file of the check to a phone’s camera app, “fooling” it into thinking it is looking right at the check. Using the zoom function on the phone, the tester has the option to simulate the distance of the check from the phone, determining how far the phone can be from the check to record accurate data.

    Challenge #2: Perform mobile testing on different devices and versions to make sure each picture is of sufficient quality to read the data correctly.

    Some phone cameras work better than others. Some versions of smartphones work better than others. It is essential that the mobile testing tool the banks use is able to work on all operating systems, devices and versions; otherwise, the banks would have to buy multiple testing tools and hire additional staff to operate each tool. And anything that increases complexity also increases the possibility for error.

    Challenge #3: Verify that the data being read is what appears on the check.

    Once the picture is taken, the mobile app retrieves the following information: the date, who is writing the check, who the check is being written out to, the check number, the bank and bank account of the payer and, most importantly, the amount. There is no room for error. The best way to test is to take hundreds of checks, all with their information stored in a database, and through numerous combinations of smartphones, versions and mobile operating systems take pictures of the checks, recording what it determines to be the information each picture contains.

    The phone’s recorded data would be checked with the database of the “real answers.” The mobile testing process continues until the apps are perfect in every detail from every execution.

    Once these challenges were met, the arduous chore of depositing a check became a convenience that you can take to the bank–or not.