DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Automated Testing: The Missing Piece of Your CI/CD Puzzle
  • Chaos Engineering: Path To Build Resilient and Fault-Tolerant Software Applications
  • The Role of Threat Modeling in Software Development: A Cybersecurity Perspective
  • How To Check Office Files for Macros Using Java

Trending

  • How To Learn Secure Software Development Lifecycle (SDLC)
  • Microservices With Apache Camel and Quarkus
  • TypeScript: Useful Features
  • Graph Databases: Unleashing the Power of Relationships
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. Security and Testing

Security and Testing

When your QA department shifts its testing from in-house to online, do QA management and staff also shift their understanding of security from “stand-alone machines” to “somewhere out there on the Internet”?

Michael Churchman user avatar by
Michael Churchman
·
Jun. 10, 16 · Opinion
Like (4)
Save
Tweet
Share
1.70K Views

Join the DZone community and get the full member experience.

Join For Free

Is your test environment secure? Do you know who has access to your test data, your source code, your design specifications?

There was a time, back in the days of stand-alone test systems and networks that were strictly local-area, when those questions would have been easy to answer. A co-worker or two might have been looking over your shoulder, but that would have been about it.

These days, however, applications are exposed to the public web, and such questions can have serious implications for your software’s security and your company’s bottom line. Software and IT companies may still have physical locations, but much of the development and testing is done off-site, by employees, contractors, and services that transfer data over the Internet, such as cloud-based testing solutions. That is why picking one who cares about your application security is important. Lets look at the risks, then at what a good solution looks like.

Most companies are reasonably security-conscious when it comes to software development, but does that security consciousness extend to your testing process and suite? For many companies, using an Internet-based testing service just makes good sense from both a practical and economic point of view. But when your QA department shifts its testing from in-house to online, do QA management and staff also shift their understanding of security from “stand-alone machines safe behind four walls” to “somewhere out there on the Internet”?

What’s at Stake

Consider what can be at stake if outside parties gain access to your test data or your test environment:

IP Theft

Unfortunately, not everybody in business sticks to the rules of fair play—and that includes the technology sector. Intellectual property is a valuable commodity, and for many technology providers, it is their main asset. This is particularly true for smaller companies and startups, which may not have had time to develop other assets, such as name-recognition or a reputation for high-quality products or services. IP is not hard to steal, since it generally consists of information that can be easily copied, compressed, encrypted, and transported. Often enough, sufficiently detailed (or even general) knowledge of an idea is sufficient for it to be stolen. If you are testing a feature or technology that is worth stealing, and if there is a way for IP thieves to gain access to your test environment, there is a reasonably good chance that they will break in. When that happens, you may find yourself not only competing with knockoffs of your software-in-progress, but also fighting in court to regain control of your proprietary technology and data.

Competitors

If you’re doing anything worthwhile or potentially money-making, you have competition—and if your competitors are smart (which they almost certainly are), they’re watching you. They may play a cleaner game than IP thieves, but they want to know what you’re planning, what new technologies and services you’re in the process of implementing, how far along you are in developing them, and how well they’re working. Needless to say, if they know what mistakes you’re making, they can learn from them as quickly as you can. If your online test environment is not secure, it’s possible that your competitors have access to your test results, and may even be able to observe your tests while they are in progress. A test suite can give a sense of code, functionality, and potential issues and weak spots in your application. They’ll know what new features and technologies will be in your next release, and they’ll have a head-start on adding competing versions to their own products. If they can learn enough from watching you, they may even beat you to the market.

Just Plain Privacy

Maybe you’re not testing anything that can be easily cloned by competitors or stolen. Maybe you’re working on things such as better implementations of known technology, and a new user interface that incorporates your brand-new, still-under-wraps company logo. There still may be some major security issues to keep in mind when it comes to online testing.

Consider this all-too-familiar scenario: Hackers break into a site, dig out some attention-getting information, and spread it all over the Internet. Very often, it turns out that what was mildly entertaining to the hackers is embarrassing or even damaging to the people and organizations affected by the leak. Do you want your upcoming feature list to become public knowledge while those features are still in the early development phase? Do you want your raw test data posted for anybody to see? Do you want your pre-release bugs to become just another occasion for lulz? Just one little break-in, into a non-secure test environment, could do all of that.

Looking for Security

How do you find a secure online test environment? What are the key elements of online test security?

Besides such basics as a secure test infrastructure and physical on-site security, a truly secure online test service (such as Sauce Labs) should provide a suite of strong test-oriented security features:

  • Dedicated, One-Time Virtual Machines. Each test VM should be spun up, used only for a single test, and then destroyed. VMs should not be recycled for multiple users, or even for multiple tests by the same user.
  • Secure Communication. Client communication with the test system should be by secure VPN or tunneling. Client test scripts and data should only be cached temporarily on the test-system side, and never stored. Only the current test VM should be allowed to communicate with the client.
  • No External Communication. All inbound channels of communication with the test VM other than client VPN/tunneling access should be disabled.
  • No On-Site Storage of Test Data or Artifacts. Test data and other artifacts should never be stored at the test site. They should only exist in RAM on the test server, and should be sent to the client via secure connection. If they are stored as part of the test service, such storage should be in a secure cloud-based location, it should be for a limited time, and it should only be at the client’s discretion.

If an online service does not offer security features such as these, you cannot count on it to provide you with a secure testing environment. A genuinely secure software testing service, on the other hand, can guarantee that all of your test data will truly be for your eyes only.

Application security Test data

Published at DZone with permission of Michael Churchman. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Automated Testing: The Missing Piece of Your CI/CD Puzzle
  • Chaos Engineering: Path To Build Resilient and Fault-Tolerant Software Applications
  • The Role of Threat Modeling in Software Development: A Cybersecurity Perspective
  • How To Check Office Files for Macros Using Java

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: