Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27221PUBLISHED: 2021-01-21In Eclipse OpenJ9 up to version 0.23, there is potential for a stack-based buffer overflow when the virtual machine or JNI natives are converting from UTF-8 characters to platform encoding.
CVE-2021-1067PUBLISHED: 2021-01-20NVIDIA SHIELD TV, all versions prior to 8.2.2, contains a vulnerability in the implementation of the RPMB command status, in which an attacker can write to the Write Protect Configuration Block, which may lead to denial of service or escalation of privileges.
CVE-2021-1068PUBLISHED: 2021-01-20NVIDIA SHIELD TV, all versions prior to 8.2.2, contains a vulnerability in the NVDEC component, in which an attacker can read from or write to a memory location that is outside the intended boundary of the buffer, which may lead to denial of service or escalation of privileges.
CVE-2021-1069PUBLISHED: 2021-01-20NVIDIA SHIELD TV, all versions prior to 8.2.2, contains a vulnerability in the NVHost function, which may lead to abnormal reboot due to a null pointer reference, causing data loss.
CVE-2020-26252PUBLISHED: 2021-01-20
OpenMage is a community-driven alternative to Magento CE. In OpenMage before versions 19.4.10 and 20.0.6, there is a vulnerability which enables remote code execution.
In affected versions an administrator with permission to update product data to be able to store an executable file on the server ...
User Rank: Apprentice
8/20/2019 | 10:14:54 AM
Overall, I feel like this is an article trying to play 'devil's advocate' for DevOps teams and developers. I understand where you are coming from for most of the claims made on the post and can even get behind some of the 'myths' but the "Shift-left" one does not really make sense. You are not supporting the case that "Shifting security to the left" is a myth, you are merely saying that legacy tools shouldn't be pushed on DevOps teams. A stronger claim would try to explaining that 'shift left' is an impossible task or that it does not result in cost savings, which, is quite the opposite; but that's what I would do if I am trying to debunk that claim.
Also, shifting secuirty to the left is not just about the tools but also about processes that need to be in place to support secuirty through the pipeline. An example of this would be architecting an application with security in mind, threat modeling, having 'security standards' in place so developers can reference them as they start to code, providing training to developers and DevOps team on application security topics so they can have an existing awareness prior to start building their applications. I feel like the article is norrowing the definition of shift left security to 'archaic tools' when it's quite the oposite (At least in my experience).
Finally, I would have added a final myth saying that "Security is only the responsability of security professionals" because that is not the case. In this day and age, everyone in a corporation is responsible for security and should be held accountable for it; if I click on a phishing email, I am sure I would get in as much trouble (if not more) as the team managing the email security tool. So, ultimetely, a better approach would be to marry development and security and have DevSecOps instead of just SecOps.
Hope to see more DevOps and AppSec articles! :)