I’m sure this is the only community that might pay attention to a software BOM as mentioned in the article, but this is a great idea and makes a lot of sense (to me as a consumer at least).
Developers are relying more and more on automated scanners and the likes to manage this. Your modern python or javaScript stack just has way too many packages and they change daily. Just look at your dependency lockfile balloon when a random dependency updates a point and brings in a few more packages. It’s really a horrible thing.
I’d like to say the scanners were fast but not fast enough because the first wave of attacks was nearly instant. This was definitely a nightmare scenario where a simple unauthenticated GET could pull in a kit that was already live and ready to go.
I don't think anyone in the Java community is surprised to find they have a dependency on Log4j. It's one of those libraries used so widely that it's practically stdlib.
In the production of electronic things I've been pointing out that software needs to be on the BOM for other reasons. It is so often overlooked and considered zero cost even though companies pay people to develop it.
Making people look at a BOM would also discourage the mess that is npm.
Most systems use package management now; npm is only the poster child.
Reviewing a stack of BOMs is going to be a challenge for any organization. Say your production Linux has 1000 packages. Each of those might have hundreds or thousands of deps in varying versions, in their respective package managers (BOMs).
Business needs to step up its process game. How are BOMS (dep lists) reviewed? Do we expect zero CVEs? How do you filter out false positives, or irrelevant ones? Do you dump everything with that dep or help the maintainer fix it? Many questions.
We do something along this axis with our products. We have to be able to provide B2B software that will be stable on timelines measured in half-decades (per contractual requirements), so the specific vendors we decide to depend upon are a huge part of our decision making process. I will happily admit we probably wrote a little bit too much stuff in-house, but the number of clear wins easily outweighs the "no DIY allowed" concerns.
Getting us to vendor out something like logging/tracing/telemetry would take an act of god at this point. We explicitly spent a week ripping out Microsoft's byzantine logging from AspNetCore in favor of something we could trust and understand. Our entire logging framework now lives in 1 class file and consists of maybe 30 useful lines of source code. None of them have the capability to reach out to a remote host, download a DLL and then execute it in the current context. This sort of problem we are seeing with Log4j today is precisely the sort of experience we hope to avoid by doing a lot of our tooling in-house.
I think those who parroted "don't reinvent the wheel" over and over like it's some doomsday cult should accept some shame for the situation many developer ecosystems find themselves in today.
Sentry is an open-source crash reporting platform that helps hundreds of thousands of software teams discover, triage, and resolve production software issues faster, so they can spend less time debugging and more time building software.
Our product is 100% open source (https://github.com/getsentry/sentry), yet we've found serious commercial success. We're up to thousands of customers and 80 people across our SF, Austin, and Vienna offices. I think our Instagram account (https://instagram.com/sentry.io/) illustrates our quirky company culture much more effectively than I can describe here.
Like everyone else, we're hiring for all our engineering teams all the time (https://sentry.io/careers/), but specifically I'm searching for a software engineer with a passion for revenue + data. We rolled our own billing and subscription services years ago, and we need to scale this critical piece of our infrastructure for the future. Find more about this role at https://sentry.io/careers/1258340/.
Our API Banking team uses Clojure to power production public-facing APIs at Silicon Valley Bank (http://docs.svbplatform.com). Great fit for our use case; we can leverage lots of existing banking-related Java libraries while still writing clean, concise, and functional code.
We have a hackathon coming up on June 15 in SF and we'd love to find even just one Clojurist who wants to attend to make it worth our while to build out a clojure SDK :P Contact mclarke@svb.com if you're interested in more info.
Silicon Valley Bank | API Banking Engineer | San Francisco, CA | Full-Time | Onsite / Remote (US) http://docs.svbplatform.com
Enable the world of FinTech by building public APIs for commercial banking. We're using clojure & postgres to expose brand new, easy to use, well documented RESTful interfaces for clients. Among other projects we work on, our small team created the technical integration with Stripe that powers Atlas (https://stripe.com/atlas). Our team consists of former Facebook, Disqus, and Standard Treasury (YC S13) engineers; startups are in our DNA.
With an aggressive roadmap of new products we'd like to launch in 2017, we're looking to expand our team to help deliver new APIs. While we don't currently have any full time remote employees on our team, we are open to remote US-based engineers helping us become a fully-distributed team.
Our interview process is designed to be respectful of your time; we have a short (~1h quiz) to get a baseline assessment of your technical skills, followed by a broader parsing problem (~4h project) to understand how you solve technical problems in a more realistic scenario. Both steps can be submitted on your schedule. These code samples minimize complications with whiteboard interviews and establish a consistent sample for all applicants.
Unfortunately, we're not able to provide detailed feedback on individual submissions, and we can't sponsor visas at this time.
This is the third or fourth month in a row that we're posting this same job post, and we have met many great folks (especially those as enthusiastic about Clojure as we are!), some of whom have joined our team. We've grown and will continue to grow as we build this product into a world-class banking API. Come join us!
Separately, we have a product manager role now available as well, where you can help us define and execute against the aggressive roadmap we have in front of us. More info on that role is available here: http://docs.svbplatform.com/jobs/pm.html
Contact Mike at api-jobs@svb.com for more information and to apply.
Silicon Valley Bank | API Banking Engineer | San Francisco, CA | Full-Time | Onsite / Remote (US) http://docs.svbplatform.com
Enable the world of FinTech by building public APIs for commercial banking. We're using clojure & postgres to expose brand new, easy to use, well documented RESTful interfaces for clients. Among other projects we work on, our small team created the technical integration with Stripe that powers Atlas (https://stripe.com/atlas). Our team consists of former Facebook, Disqus, and Standard Treasury (YC S13) engineers; startups are in our DNA.
With an aggressive roadmap of new products we'd like to launch in 2017, we're looking to expand our team to help deliver new APIs. While we don't currently have any full time remote employees on our team, we are open to remote US-based engineers helping us become a fully-distributed team.
Our interview process is designed to be respectful of your time; we have a short (~1h quiz) to get a baseline assessment of your technical skills, followed by a broader parsing problem (~4h project) to understand how you solve technical problems in a more realistic scenario. Both steps can be submitted on your schedule. These code samples avoid complications with whiteboard interviews and establish a consistent sample for all applicants.
Unfortunately, we're not able to provide detailed feedback on individual submissions, and we can't sponsor visas at this time.
Contact Mike at api-jobs@svb.com for more information and to apply.
Silicon Valley Bank | API Banking Engineer | San Francisco, CA | REMOTE(US) INTERNS http://docs.svbplatform.com
Enable the world of FinTech by building public APIs for commercial banking. We're using clojure & postgres to expose brand new, easy to use, well documented RESTful interfaces for clients. Among other projects we work on, our small team created the technical integration with Stripe that powers Atlas (https://stripe.com/atlas). Our team consists of former Facebook, Disqus, and Standard Treasury (YC S13) engineers; startups are in our DNA.
With an aggressive roadmap of new products we'd like to launch in 2017, we're looking to expand our team to help deliver new APIs. While we don't currently have any full time remote employees on our team, we are open to remote US-based engineers helping us become a fully-distributed team.
We're also accepting intern applications for summer 2017.
Contact Mike at api-jobs@svb.com for more information and to apply.
why using a throwaway account? if you are going to dis someone, at least stand up and don't hide.
most all companies ignore emails upon rejection (at least in my exp), don't take it personally.
my experience with svb has been the complete opposite. the initial programming test was short and sweet, shouldn't take much more than an hour. they reached out a bit after i submitted the quiz.
i've had a chance to speak with the crew and they are a great bunch.
Silicon Valley Bank | San Francisco, CA | REMOTE (US) | FULL TIME | INTERNS
Enable the world of FinTech by building public APIs for commercial banking. We're using clojure & postgres to expose brand new, easy to use, well documented RESTful interfaces for clients. Among other projects we work on, our small team created the technical integration with Stripe that powers Atlas (https://stripe.com/atlas). Our team consists of former Facebook, Disqus, and Standard Treasury (YC S13) engineers; startups are in our DNA.
With an aggressive roadmap of new products we'd like to launch in 2017, we're looking to expand our team to help deliver new APIs. While we don't currently have any full time remote employees on our team, we are open to remote US-based engineers helping us become a fully-distributed team.
We're also accepting intern applications for summer 2017.
Contact Mike at api-jobs@svb.com for more information and to apply.
I work with Mike at SVB and wanted to add that we are particularly interested in remote contractors. If you are a great engineer who is also remote (US only) and also a contractor, please contact us.
