Tag: security vulnerability

  • Cybersecurity Fears May Drive Shift to Managed DevOps

    Cybersecurity Fears May Drive Shift to Managed DevOps

    Should organizations consider using a managed service for DevOps to keep their platforms up to date and secure?

    The recent disclosure of a vulnerability that would allow open source Jenkins continuous integration/continuous delivery (CI/CD) platforms to be employed to launch a distributed denial of service (DDoS) attack highlights how challenging it is to secure the platforms on which many organizations now depend to build their most critical applications.

    The CVE-2020-2100 bug theoretically would have allowed cybercriminals to employ the Jenkins UDP discovery protocol to bounce traffic between servers until they could no longer respond. That same flaw also could be employed to launch DDoS amplification attacks against platforms connected to the internet. Those attacks can’t be stopped unless one of the servers is rebooted or its Jenkins service is restarted. The specific vulnerability discovered was fixed last month in Jenkins v2.219. IT organizations can either upgrade their Jenkins servers, disable the UDP discovery protocol or block the UDP port 33848.

    Tracy Miranda, director of open source community for CloudBees and member of the governing board for the Continuous Delivery Foundation (CDF), which oversees the development of Jenkins, said the bug itself is at best of medium severity. However, now that it’s been disclosed, the race is on to patch Jenkins servers or block UDP port 33848 before cybercriminals exploit the vulnerability on any public-facing instance of a Jenkins server.

    Given the fact that most IT organizations may not have resources at hand to patch their Jenkins servers quickly, Miranda said these and other potential future cybersecurity issues are a testament to why more organizations should rely on instances of Jenkins that are managed by third-party providers on their behalf. Organizations are spinning up more Jenkins servers than ever as they move to accelerate application development, and by relying on a managed service provider (MSP) to manage Jenkins, IT teams can focus more of their efforts on building and deploying applications rather than on managing CI/CD platforms.

    These days, more organizations are looking at DevSecOps as a best practice. Much of that focus, however, is on securing the applications that DevOps teams create; not nearly as much attention is being paid to securing the underlying platforms on which those applications are being built and deployed.

    It’s too early to say to what degree cybersecurity concerns might push IT organizations toward managed DevOps platforms. However, the more that cybersecurity teams participate in the DevOps process, the more they will ask questions about the fundamental security of the underlying platform.

    Of course, many IT teams often view managed services provided by third-party vendors as a threat to their existence. Nevertheless, DevOps platforms are among the most complex and expensive platforms to manage. In fact, that complexity is one of the main reasons so many organizations have hired site reliability engineers rather than relied on traditional IT administrators to manage DevOps platforms such as Jenkins. The issue that often comes up is just how many SREs an organization needs to hire before the cost of a managed DevOps platform becomes economically more appealing.

    — Mike Vizard

  • Managing Open source software components

    Managing Open source software components

    Building any software need lots of efforts including resources, time, money, etc. It is really a great pleasure when it goes live or gets released. In parallel, there is always a chance that bugs may put the release in a difficult condition even after multiple rounds of testing. Teams can fix bugs related to software features or functionality, but the ones which can hit badly are

    • Security vulnerability.
    • Licensing risk of open source component.
    • Outdated open source component.

    The world is moving towards open source in a very fast pace and its growing use in software as components inside the application. Open source components are available free for us, however there could be more risk while using them. A product which is paid and commercial is bound to fix issues and provide adequate support for any vulnerability or security issue and Licensing, But open source software may have a little more of a high risk and its very important to be updated about new releases and available bug fixes.

    If open source components are not monitored properly and keep up to date, that may lead the software to become vulnerable.

    Above checks needs to be done during the development phase and ruled out any discrepancy related to security or legal. This check can be included as part of build process to make sure it does not pass the fist barrier and caught even before hitting the testing phase. Eventual this can save development and testing effort and their time.

    There are tools available which can take care of some/all of verification of open source components in various phases.

    Artifactory

    This tool can verify the license of the open source component and check its compatibility with various definitions. You can even add your own license definition as per your requirement.

    Sonatype Nexus and WhiteSource

    These tools will verify the license and keep the component information up to date. They will check for any updates,  bug fixes for any vulnerability issues and notify the user. These tools can do component security vulnerability and license analysis with the latest available information.

    Security issues would be the last thing any software developer wants. Even small legal or security problems can put your system/software in a dangerous situation. Better to secure software first then fixing it later.

    Reference ->

    http://www.scmtechblog.net/2015/06/managing-open-source-component.html

    http://www.scmtechblog.net/2015/03/maven-repository-tools-comparison.html