I am aware of no such service that could be adapted for the communicated needs, though I am not sure the intelligence exists to create one that provides value without significant ongoing consumer-side attention.
I can think of 4 sets of information sources to pay attention to, listed below. Unless the specific circumstances of your business require attention to us-cert, bugtraq, or cvedetails, I would not include those in a list of useful sources.
The 4 sets are:
- operating system
- infrastructure provider
- individual software providers
- development platform/libraries
The general rule is- in the absence of an aggregated configurable source, the most important individual sources to pay attention to are the providers of the software and infrastructure being utilized, both in an operational context and in a development context. For those, follow both any specific security and releases announcements list as well as their general technical blog. Ubuntu's blog is where news about their response to POODLE was distributed (e.g. http://blog.canonical.com/2014/10/16/ubuntu-security-update-on-poodle-cve-2014-3566-and-sslv3-downgrade-attack/).
The OS is one layer in this sandwich. Below the OS, if the servers are virtualized in a cloud environment, then this rule comprises the cloud provider- AWS, Google, Digital Ocean, etc. AWS generally speaking has blogs for each major service- those will communicate information relevant from a security context.
If the virtualization or cloud platform also includes containers, then the blog, security, and releases announcements of the upstream container provider- Docker, linuxcontainers, etc- is worth following.
Above the OS are individual applications. These may be delivered by the OS provider but are nevertheless independent sources of news and information, because the curation filter of the OS provider is going to exclude important context related to features and configuration of these applications.
The importance of attending to these depends on their role in your infrastructure, and their role can be graded on two dimensions-
- how visible they are to potentially malicious sources of traffic
- how important they are in terms of securing your livelihood
You may have an important database that itself is not publicly exposed to potentially malicious traffic but it is nevertheless desirable to attend to their releases, security list, and technical blog as important architectural and defensive configuration information will get communicated there that will not come through other sources.
Similarly, you probably run nginx or apache web servers and some sort of application server. Ubuntu of course collects and processes information from the releases, security announcements and technical blogs of these projects, but again their curation filter will exclude specific issues of configuration and deployment that these projects will inform their users about directly.
As a web development shop, presumably your team works on one or more platforms- Node, Rails, Spring, React, whatever- consuming the platform releases of both the major providers and also of the library developers operating in that ecosystem and then producing software for your customers. Following the announcements and blog of both the platform and the library providers whose work you consume, and keeping up to date on dependencies, is important. Here there are some new services that focus on finding and curating vulnerabilities found through static analysis of development platforms and libraries, and then integrating that information into continuous integration/delivery workflows- these services are worth considering for your team.
The general rule again is- if you consume a service or an application as a dependency in your operational infrastructure, or if you consume an application or library in your development infrastructure, then following the announcements of those specific upstream providers is at this current state of maturity of the industry important for security.
The downstream providers who package and distribute software from upstream do not typically solve for configuration and deployment use cases that are security sensitive and that the upstream software providers spend a lot of time thinking about.
Finally, this is a lot of potential material to follow, which itself is an important point about attack surface. Because all software contains vulnerabilities, the more one consumes and utilizes the wider one's attack surface becomes. Consuming some software for its functionality and not attending to its upstream stream is an off-balance-sheet form of technical debt.
Hope that's helpful.
