ReliQuery.io

Our dear friend Richard (Dick) Brooks has been talking about SBOMs for so long we thought we'd give it a go and generate one for ReliQuery.io. ReliQuery.io is a combination of Python, Rust and Go on the backend, so we weren't sure how easy creating a combined SBOM was going to be. It was astonishing simple to do, at least using the OWASP CycloneDX SBOM/xBOM Standard. We're not sure why we resisted doing it before now. Thanks for the gentle nudges Richard (Dick) Brooks!

Datadog's threat insights report (https://lnkd.in/e6ADMmfM) has inspired us at ReliQuery.io. 80% of Python malware uses source package attacks! We've always given you the ability to curate the packages that you want to allow or deny and to analyze packages that you upload, but now we've also given you the ability to stop source package installs at the index level, thereby eliminating this threat at the source. We will be turning this on by default so that you are protected until you tell us differently. We will also be implementing Datadog's Malicious Software Packages Dataset (https://lnkd.in/eabSssAV) in the next couple of days into every Python ReliQuery that you use. It's going to be always on, permanently protecting you at the index level from packages that have been human-triaged as malicious. Finally, we will be implementing the OSV database in the coming weeks and allowing you to set the risk threshold that you are comfortable with (but not allowing you to go above the danger zone). Any packages that exceed that risk threshold will be blocked at the index. Of course, if you really must have those packages you can always fork/download them on your own, fix the bad code, and upload the now secure package to your ReliQuery. What does that mean? ReliQuery.io will be the simplest Secure By Default Private Python Index available, and you can sleep a little easier.

80% of Python supply chain attacks occur though source package installation? That gives an entirely new meaning to "setup"! Dan Lorenc is right about being binary-only with Python; given this, we should probably never install a source package again. But we don't think you should wait until the package managers get the message, nor should you rely on a local developer's configuration of their package managers to keep you safe. So we added the ability in ReliQuery.io to completely block source packages at the index level. As long as your developers (or servers) are using ReliQuery.io as their index you'll never have to worry about them accidentally installing from a source package again!

Yep. We do love Storj. Check them out!

Are you a member of an Internal Tools/Core Engineering/Software Infrastructure Team building libraries and applications in Python? Are you looking for a simpler way to distribute those libraries and applications securely while using the standard tools (pip, pipx, poetry, etc.) that your development teams know? Are you looking for a way to increase your supply-chain security by managing access to Python packages with vulnerabilities? Give ReliQuery.io a try! It does all of the above (and more), and you don't need a training class or a certification to run It.

Are you a Data Scientist/Data Engineer delivering Python scripts to your internal customers? You should probably think about delivering those as Python packages that are installable as executables (e.g. - using pipx). Why? Because that gives you complete control over the installation environment, including the packages that your script requires, and it gives your internal customers an easy button for installing and upgrading what you produce. If this sounds like a good idea to you, then you also need to think about how you effect distribution. Ideally, distribution should be simple (for you and your customers), private (your work is for your company, not the world), available no matter where your customers are, and inexpensive. That's ReliQuery.io. Give us a try today. When you sign up we'll give you a month free on your first ReliQuery.

Are you a member of an Internal Tools/Core Engineering/Software Infrastructure Team building libraries and applications in Python? Are you looking for a simpler way to distribute those libraries and applications securely while using the standard tools (pip, pipx, poetry, etc.) that your development teams know? Are you looking for a way to increase your supply-chain security by managing access to Python packages with vulnerabilities? Give ReliQuery.io a try! It does all of the above (and more), and you don't need a training class or a certification to run It.

There are three things that are required to achieve supply chain security in a Python development environment. 1. Visibility into the packages that your software is using. 2. Vulnerability analysis on the packages you are using. 3. The ability to deny access to an open-source package or a specific release of that package if It fails your vulnerability risk assessment. You cannot achieve any of these three by simply using PyPI directly. But you can by using ReliQuery.io! 1. ReliQuery.io will notify you about every package and version that is downloaded or uploaded to your Private Python ReliQuery, including the user that did so. This allows you to maintain a comprehensive record of every package used by your organization and the frequency of the use. It also allows you to perform analysis of your own on new packages to your team. 2. ReliQuery.io will perform Bandit vulnerability analysis on every package that you upload, and will include the report in the upload notification. This allows you to maintain a comprehensive record of vulnerabilities introduced by your team and allows you to intercept and rectify them near the point of creation. 3. When you receive notification that a new package/version has been downloaded, you can access that package/version directly using the API, execute your own vulnerability analysis on it, and if that analysis fails you can deny access to that package/version using the API. ReliQuery.io gives you the tools to ensure the sanctity and security of your software supply chain. Give us a try today!

We created ReliQuery out of frustration in finding a way to manage and share the private Python packages that we were building. Our requirements: 1 - It must integrate with existing tools - pip, poetry, twine, etc. 2 - It must be so simple that both admins and users can simply pick it up and use it. 3 - It must be inexpensive, and It must be paid as we use it. 4 - It must provide a mechanism to filter open-source packages for supply-chain security. 5 - It must provide a mechanism to filter the packages that a user can access for distribution requirements (e.g. - licensing, 3rd party partners, etc.). The existing methods just didn't meet the requirements: 1 - Using open-source was too labor intensive. 2 - Existing commercial offerings were too expensive and complex. 3 - Other methods (direct pull from GitHub, AWS CodeArtifact) require authentication outside of what is supported by standard tools. 4 - Most methods often provided little or no support to filtering open-source packages or limiting the packages that a specific user can access. If you build private Python packages (either libraries or executables) and want a better way to manage them, check out ReliQuery.io! When you sign up we'll give you a coupon for a free month so that you can try It out for free!

Open source Python packages are amazing. Open source Python packages are terrifying. Allowing your developers to use open source is essential to modern development, but unrestricted use of any package in PyPI can leave you vulnerable. PyPI is the Wild West; anyone can publish anything, including bad actors. So what's a responsible (and paranoid) CTO to do? 1) Go to https://reliquery.io and create a Private Python ReliQuery. 2) Once your ReliQuery is created, delete the default upstream (pypi.org). This makes your ReliQuery only serve those packages that you explicitly upload. 3) Create users for your ReliQuery to read and write packages (you'll probably want these to be separate users). 4) Audit all of the packages that you are currently using from PyPI and list them in a requirements.txt file. Download them (you can use pip to do this) and then upload them into your ReliQuery (you can use twine to do this with your "write" user). 5) Configure all of your build tools and servers to point to your ReliQuery, using one of the "read" users you created in step 3. 6) Block access to pypi.org from your firewall. This makes It much harder for a developer to bypass your controls (although It does not make It impossible). You've now created your very own, fully controlled python package index in the cloud and integrated It into your operations. All the sweetness of Python open source without any of the bitter aftertaste! Your security and compliance officers will send you Christmas cards.