Container Security

The eRTC container scanner does the layer-wise static analysis of the container that is running on the client’s machine. We ensure that a hardened and certified image is delivered to our customers, using our own private repository. By providing vulnerability reports to the customers (on-demand), we ensure the quality of our deliverables.

The report can be viewed in the container security section of the administrator portal.
Benefits: Since it is providing on-demand security scanning, it gives an added cushion, allowing customers to rest assured that the containers provided are secured and safe to use.

The methods for securing containers have morphed alongside the evolution of infrastructure. The current era is to manage the dynamic infrastructure running on application stake clusters.

Automation has shifted security across the standard definitions so far - because containers encapsulate all their dependencies, they can move easily from a development environment to a test environment to a production environment, making frequent deployments by way of automation the new reality.

Containers scale up and down far more significantly; applications built using a microservices architecture consists of many interrelated entities. The number of deployed entities can grow quickly as orchestrators seamlessly scale your apps up or down according to demand. Additionally, manually creating and maintaining security rules for each entity is impractical.

Our development cycles have shrunk from months to days or hours. Developers, as they aim to deliver business value, are deploying more quickly than ever before using CI-CD pipelines in times measured in hours and days, not months. Integrating security into CI/CD workflows and implementing DevSecOps best practices while in the development, building, testing and delivery phases provides incredible security advantages in the world of containers that we use.

Automation has shifted security across the standard definitions so far - because containers encapsulate all their dependencies, they can move easily from a development environment to a test environment to a production environment, making frequent deployments by way of automation the new reality.

• Image vulnerabilities and compliance concerns: Vulnerabilities can impact container images just like any other legacy code framework, which is why scanning images for both vulnerabilities and compliance issues, building a bill of materials, identifying any embedded secrets or malware, and correlating risk to individual image layers ensures developers are building secure images.

  Additionally, organizations need to remember drift can be a big problem for containers. An image that was scanned and passed your vulnerability and compliance requirements today may not be secure in the future; new threat data can identify components that are actually vulnerable when they were originally thought to be secure. This is why today’s enterprises need to continuously monitor images and run time-scanning containers for drift.

• Container runtime protection: The container runtime is one of the most difficult parts of a container stack to secure because traditional security tools were not designed to monitor running containers. They can’t peer inside containers or establish good baselines for what a secure container environment looks like. Our Runtime security focuses on securing the running dockers, rather than only relying on network-level security tools to keep them safe using the security agents deployed within the environment.

  Our dev-ops, infrastructure, and security teams are embracing the concept of immutability: replacing existing containers with new containers whenever you make an update to your applications or services. Immutability presents security advantages, so users aren’t attempting to perform live updates on running containers, preventing configuration drift and poor enforcement of security policies.

• Compliance: Protecting the Host OS and meeting the CIS compliance. The OS that hosts your container environment is perhaps the most important layer of the stack, because an attack that compromises the host environment could provide intruders with access to everything else in your stack. That’s why hosts need to be scanned for vulnerabilities, hardened based on specific CIS Benchmarks, and protected to prevent improper access control (Docker commands, ssh commands, sudo commands, etc.) or file tampering. With our paid plans, we are providing the underlying host vulnerability status using our host agents.

  The roadmap is to make a workflow where the customer can raise a ticket with RBN support to initiate the remediation of the open vulnerabilities as per their environment needs.

• Configuration:

  • For Free Plans: Everything is autoconfigured.

    For Hosted Plans: Everything for container security and compliance will be autoconfigured, based on the plan purchased by the customer. Customers can initiate on-demand scans as per the provision.

  • For On-Premise:

    We can offer basic vulnerability insights from our private registry in future with Harbor.

    We can offer an Integration Module with the customer’s existing vulnerability scanning solutions.

    We can offer/sell/recommend a security solution to be purchased for best results. (NOTE: For now, we are using Qualys to be used as container security and compliance).

• Container Security:

  Number of open vulnerabilities identified for each container

  CVE numbers assigned for it

  Possible remediation method by daemon/tool vendor

  Severity level of each vulnerability

• Compliance:

  Host wise results for CIS compliance based on customer purchase/deployment plans

  Level of severity

  Remediation information

  CVE numbers